CVE-2024-9612

Executive Summary

CVE-2024-9612 is a security vulnerability in danswer-ai/danswer v0.3.94, an open-source AI-powered search platform. The flaw resides in the authorization logic for the search page visibility feature. Administrators can configure the search page to be invisible to regular users via the front-end interface. However, the back-end API does not enforce this visibility restriction. This allows authenticated attackers with low privileges to directly call the back-end API endpoints that power the search functionality, effectively bypassing the administrator-set visibility controls. The vulnerability has a CVSS score of 6.5 (Medium), indicating a moderate risk of unauthorized access to search features and potentially sensitive data indexed by the platform.

Supply Chain & Package Security

This vulnerability affects the danswer-ai/danswer Python package (PyPI ecosystem). The vulnerable version is v0.3.94. As of the latest analysis, no official patch has been released. Organizations using this version should consider it a supply chain risk and monitor for updates from the vendor.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – An attacker needs a valid low-privilege user account.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – Limited unauthorized access to search data.
• Integrity Impact: Low (I:L) – Potential to modify search results or settings.
• Availability Impact: Low (A:L) – Potential to disrupt search functionality.

Threat Level: Medium. The vulnerability requires authentication but allows low-privilege users to bypass administrative controls, potentially exposing sensitive information or enabling further attacks.

Deep Dive & Mechanics

The vulnerability stems from a missing authorization check in the back-end API endpoints that handle search functionality. In danswer-ai/danswer v0.3.94, administrators can set the visibility of pages (including the search page) via the front-end. This setting is stored in the database and used by the front-end to hide UI elements. However, the back-end API does not verify this visibility flag before processing requests.

Technical Flow:

1. An administrator sets the search page visibility to "invisible" for regular users.
2. The front-end hides the search page UI, preventing normal users from accessing it.
3. A low-privilege user (attacker) directly calls the back-end API endpoint (e.g., /api/search or similar) with valid authentication.
4. The back-end processes the request without checking the visibility flag, returning search results or performing actions as if the page were visible.
5. The attacker gains unauthorized access to search functionality and potentially sensitive data.

Root Cause: The back-end lacks a middleware or permission check that validates the visibility status of the requested page or feature. This is a classic case of missing authorization (CWE-862).

Vulnerable vs. Patched Code

Since no official patch is available, the following is a hypothetical comparison based on the vulnerability description.

Vulnerable Code (v0.3.94):

# backend/routes/search.py
@router.post("/api/search")
async def search(query: str, user: User = Depends(get_current_user)):
    # No visibility check
    results = perform_search(query)
    return results

Patched Code (Hypothetical):

# backend/routes/search.py
@router.post("/api/search")
async def search(query: str, user: User = Depends(get_current_user)):
    # Check if the user has permission to access the search page
    if not has_page_visibility(user, "search"):
        raise HTTPException(status_code=403, detail="Access denied")
    results = perform_search(query)
    return results

The patched version would include a has_page_visibility function that checks the database for the visibility setting and the user's role.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid low-privilege user account on a danswer-ai/danswer v0.3.94 instance.
• Network access to the API endpoint.

Steps:

1. Obtain a valid session token or API key for the low-privilege user.
2. Identify the search API endpoint (e.g., /api/search or /api/query).
3. Send a direct API request with the authentication token:

   curl -X POST "https://target.com/api/search" \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{"query": "sensitive data"}'
   

4. The server returns search results, bypassing the visibility restriction.

Expected Outcome: The attacker gains access to search functionality and any data indexed by the platform, potentially including confidential documents.

Blue Team (Detection & Defense)

Detection:

• Monitor API logs for direct calls to search endpoints from users who should not have access based on visibility settings.
• Look for patterns where a user accesses the search API but does not have corresponding front-end page views.

Defense:

• Implement server-side authorization checks for all API endpoints, including visibility flags.
• Use a middleware that validates user permissions before processing any request.
• Regularly audit user activity logs for anomalous API calls.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Unusual API calls to /api/search or similar endpoints from low-privilege users.
  • Repeated requests to search endpoints without corresponding front-end page loads.
• Log IOCs:
  • Log entries showing GET /api/search or POST /api/search from users with roles that should not have access.
  • Absence of front-end page view logs for the search page before API calls.
• System IOCs:
  • Unexpected search results being accessed by unauthorized users.
  • Changes to search settings or visibility flags by non-admin users.

Detection Engineering

YARA Rule

rule CVE_2024_9612_Danswer_Search_Bypass {
    meta:
        description = "Detects attempts to exploit CVE-2024-9612 by directly calling search API without visibility check"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-9612"
    strings:
        $api_path = "/api/search" nocase
        $api_path2 = "/api/query" nocase
        $auth_header = "Authorization: Bearer" nocase
    condition:
        any of ($api_path, $api_path2) and $auth_header
}

Sigma Rule

title: CVE-2024-9612 Danswer Search API Bypass
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects direct API calls to search endpoints that bypass visibility controls
author: Valters IT
date: 2024-10-27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-9612
logsource:
    category: web
    product: danswer
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem:
            - '/api/search'
            - '/api/query'
    condition: selection
falsepositives:
    - Legitimate admin users accessing the API
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-9612 Danswer Search API Bypass Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/api/search"; http_uri;
    content:"Authorization|3a| Bearer"; http_header;
    sid:1000001;
    rev:1;
    reference:cve,2024-9612;
    classtype:attempted-recon;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Restrict API Access: Use a Web Application Firewall (WAF) or reverse proxy to block direct API calls to search endpoints from low-privilege users.
2. Monitor Logs: Enable detailed logging for all API requests and review for suspicious activity.
3. User Education: Inform administrators about the vulnerability and advise against relying solely on front-end visibility controls.

Long-Term Fix:

• Apply Patch: Monitor the danswer-ai GitHub repository for an official patch and apply it as soon as available.
• Implement Server-Side Authorization: Add middleware that checks user permissions and page visibility before processing any API request.
• Code Review: Conduct a security audit of all API endpoints to ensure consistent authorization checks.

Workaround:

• If patching is not possible, consider disabling the search feature for low-privilege users entirely by modifying the back-end code to reject requests from non-admin users.

Valters IT