CVE-2026-85709 in LightRAG
Summary
by MITRE • 09/22/2026
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, the LightRAG API server returns raw Python exception text from error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py. The detail=str(e), detail=str(exc), and equivalent formatted-message paths expose server filesystem paths, database host, port, user, and database names, language-model provider diagnostics, configuration details, and Python library internals to a network client that can trigger an error. The default unauthenticated configuration makes those responses reachable without credentials, and URI-configured backends can disclose connection strings containing credentials depending on the underlying driver error. This issue is fixed in version 1.5.5.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in LightRAG versions prior to 1.5.5 constitutes a critical information disclosure flaw stemming from improper exception handling within the application's API server components. Specifically, modules such as document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py were configured to return raw Python exception text directly in response bodies when errors occurred. This implementation detail means that any unhandled or caught exceptions triggered by client interactions are serialized into the HTTP response without sanitization, effectively leaking internal application state to external actors. The core technical flaw lies in the use of statements like detail=str(e) and similar formatted-message paths which expose sensitive diagnostic information rather than generic error messages. This behavior violates fundamental security principles regarding secure error handling and input validation, allowing attackers to gather intelligence about the underlying infrastructure through controlled error induction.
The operational impact of this vulnerability is severe due to the depth and specificity of the data exposed. Attackers can trigger these errors by sending malformed requests or exploiting edge cases in API endpoints, thereby forcing the server to raise exceptions that reveal a wealth of sensitive information. This includes internal filesystem paths which aid in understanding the directory structure for further exploitation attempts such as path traversal attacks. Additionally, database connection details are disclosed, including host addresses, port numbers, usernames, and specific database names. In configurations where backends are connected via URI strings, these responses may also contain embedded credentials depending on the underlying driver's error reporting behavior. Furthermore, diagnostics related to language-model providers and internal Python library states are exposed, providing attackers with a comprehensive map of the technology stack and configuration nuances that can be leveraged for targeted attacks against specific components or dependencies.
This vulnerability aligns closely with CWE-209, which describes the generation of an error message that includes sensitive information useful to an attacker, as well as CWE-754, relating to improper check for unusual or exceptional conditions where generic handling fails to mask internal details. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior facilitates Reconnaissance techniques such as Software Discovery and System Information Discovery. The ability to enumerate database configurations and service endpoints significantly lowers the barrier for subsequent exploitation phases, including credential stuffing if passwords are leaked in connection strings or targeted attacks against specific services identified through host and port disclosures. The risk is compounded by the fact that the default configuration of LightRAG often runs with unauthenticated access, meaning these sensitive details are reachable without any prior authentication credentials, turning a simple error into a high-severity data leak vector.
Mitigation for this vulnerability requires an immediate upgrade to version 1.5.5 or later where the issue has been resolved by implementing proper exception handling practices. Developers should ensure that all API endpoints return generic, user-friendly error messages that do not reveal internal stack traces, file paths, database credentials, or library internals. It is essential to implement centralized error handlers that log detailed information securely on the server side while returning standardized HTTP status codes and minimal message payloads to clients. Additionally, security configurations should enforce authentication requirements for API access where possible to limit exposure even if similar flaws exist in other parts of the application stack. Regular code reviews focusing on exception handling patterns and automated testing with fuzzing tools can help identify and prevent such information leakage vulnerabilities before deployment into production environments.