CVE-2026-85709: Sensitive Information Exposure in LightRAG API Server

LightRAG is an open-source retrieval-augmented generation framework designed to integrate knowledge graphs and large language models for advanced information retrieval tasks. The framework exposes a FastAPI-based server component to facilitate document ingestion, graph generation, querying, and backend model configuration. By default, this API server operates without an active authentication mechanism, permitting any network client to interact with the endpoints.

Prior to version 1.5.5, the application suffered from systemic improper exception handling across its core API routes. Under normal operations, failures in network connectivity, malformed inputs, or missing files would trigger backend Python exceptions. Instead of sanitizing these failures, the API routers returned the raw exceptions directly to the clients. This architecture creates a substantial information exposure surface.

The vulnerability is tracked as CVE-2026-85709 and GHSA-hrmj-7rvj-4hg8, matching the CWE-209 classification (Generation of Error Message Containing Sensitive Information). The absolute exposure of traceback structures and connection variables lowers the technical barrier for attackers mapping the host environment, targeting database servers, or constructing secondary exploitation chains.

The root cause of CVE-2026-85709 is the widespread implementation of generic catch-all try-except structures that directly reflect system error states to HTTP responses. Specifically, across approximately 31 endpoints in modules such as document_routes.py, graph_routes.py, and query_routes.py, the developers utilized a standardized error handling pattern. This pattern caught all exceptions using except Exception as e and threw a FastAPI HTTPException with detail=str(e).

When Python serializes exceptions to string formats, the resulting string typically includes context-specific details. In the context of database drivers (such as PostgreSQL's asyncpg, MongoDB's pymongo, or Neo4j drivers), an exception caused by a failed connection, timeout, or authentication failure frequently contains sensitive configuration parameters. This metadata can include backend hostname values, internal port numbers, username strings, and database schemas.

Because the endpoints do not perform pre-execution validation or sanitize outbound error details, any backend failure exposes the internal running context. The lack of standard exception translation layers allowed operational driver failures to bypass administrative visibility and propagate raw diagnostic records directly to untrusted web clients.

The vulnerability was distributed across multiple router files. The following example demonstrates the pre-patch vulnerability structure within the document uploading route:

# Pre-patch vulnerable pattern in lightrag/api/routers/document_routes.py
@router.post("/documents/upload")
async def upload_document(file: UploadFile = File(...)):
    try:
        # Ingestion logic executed here
        await process_document_ingestion(file)
    except Exception as e:
        logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
        logger.error(traceback.format_exc())
        # VULNERABLE: Stringified exception 'str(e)' is returned to client
        raise HTTPException(status_code=500, detail=str(e))

In version 1.5.5, the maintainers implemented a two-tier remediation strategy. The primary defense introduces a centralized sanitization helper function within lightrag/api/utils_api.py. This helper captures the exception, logs the details securely on the server, generates a randomized 12-character hexadecimal correlation ID, and returns a generic client-safe HTTP response.

# Defensive mitigation helper in lightrag/api/utils_api.py
import uuid
from fastapi import HTTPException
 
_INTERNAL_SERVER_ERROR_MESSAGE = "Internal server error"
 
def internal_server_error(exc: Exception) -> HTTPException:
    # Generate a unique correlation ID for server-side log auditing
    error_id = uuid.uuid4().hex[:12]
    logger.error(
        f"Returning HTTP 500 to client [error_id={error_id}] ({type(exc).__name__})"
    )
    # Return generic error details and ID, completely hiding the exception string
    return HTTPException(
        status_code=500,
        detail=f"{_INTERNAL_SERVER_ERROR_MESSAGE} (error_id: {error_id})",
    )

All endpoint modules were refactored to replace raise HTTPException(status_code=500, detail=str(e)) with raise internal_server_error(e). To ensure complete defensive coverage, a last-resort global exception handler was registered within lightrag_server.py. This handler intercepts any uncaught runtime exceptions that escape standard router handlers, preventing the underlying ASGI server from disclosing unhandled stack trace frames.

Exploitation of CVE-2026-85709 is straightforward because it does not require authentication or complex state preparation. The attacker's objective is to systematically induce server-side exceptions and parse the reflected response structures.

Common exploitation vectors include:

1. Sending malformed JSON structures to endpoints with rigid schema validators.
2. Uploading corrupted document formats to /documents/upload to trigger file-parsing or driver-level insertion failures.
3. Initiating high volumes of concurrent requests to exhaust backend database connections, triggering connection pool exhaustion tracebacks.

When a connection or operational error is successfully induced, the unpatched server returns an HTTP 500 response containing detailed traceback metadata. From this metadata, the attacker can extract local path definitions (e.g., /opt/lightrag/workspace/config.json), active database parameters, and internal Python library versions. These details are used to perform targeted external host profiling.

The overall severity of CVE-2026-85709 is classified as Medium, represented by a CVSS v3.1 score of 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). The impact vector is limited to confidentiality. The vulnerability does not directly allow write access, system manipulation, or service disruption, which leaves the integrity and availability scores at none.

Despite the lack of direct control-flow hijacking, the exposure of internal execution parameters is a significant security risk. Retrieval-augmented generation platforms handle sensitive corporate data and interface directly with key internal datastores. Disclosing absolute directory paths and internal database credentials significantly assists attackers in targeting localized path traversal vulnerabilities or seeking lateral movement opportunities.

Furthermore, the disclosure of internal network topologies, system usernames, and configuration layouts provides the exact parameters required for offline credential brute-forcing and network scanning. This risk is amplified if the database driver prints raw authorization tokens or unredacted connection strings.

The primary remediation strategy is upgrading the LightRAG package to version 1.5.5 or later. This release enforces the sanitized generic exception structures globally and establishes the internal_server_error translation framework across all API modules.

For systems where immediate upgrades are not possible, administrators should apply the following secondary workarounds:

1. Restrict access to the API port (default 9621) using host-based firewalls, network security groups, or a reverse proxy. Limit API communication strictly to authorized internal hosts.
2. Enforce the LIGHTRAG_API_KEY environment variable configuration to block unauthenticated access across the entire API router structure.
3. Configure web application firewall (WAF) rule sets to detect and block outgoing HTTP responses containing standard Python tracebacks, exception identifiers, and server configuration structures.