LightRAG CVE-2026-85709

Exploitation requires only that the LightRAG API server be network-reachable in its default unauthenticated configuration and that the attacker can trigger a server-side exception in one of the affected routers (document, graph, query, ollama, or the server status endpoint) - no credentials or user interaction needed. The scope and value of disclosed data is amplified when backends are URI-configured with drivers whose error messages embed connection strings (then credentials leak); it is limited to reconnaissance-grade data (paths, DB host/port/user/database names, library internals) on deployments that place LightRAG behind authentication or an upstream gateway, or that use backends whose driver errors do not include credentials. Affected versions are prior to 1.5.5.

This is a genuine but modest-severity information-disclosure issue, correctly scored: the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3 MEDIUM) is internally consistent with a CWE-209 verbose-error-message flaw - remote, low-complexity, unauthenticated because the LightRAG API server ships an unauthenticated default configuration, with confidentiality-only impact (C:L) and no integrity or availability effect. No EPSS score, KEV entry, or public POC was provided in the input, so exploitation status is: no public exploit identified at time of analysis. This is not a high-CVSS-but-low-real-risk trap nor a top priority - the base rating (5.3) already reflects reality: the payoff is reconnaissance data (filesystem paths, DB host/port/user/database names, LLM-provider diagnostics, Python library internals), not direct code execution or data theft. The one signal worth weighing above the numeric score is the description's note that URI-configured backends can leak connection strings containing credentials depending on the underlying driver's error text; in that specific deployment the practical confidentiality impact edges toward credential exposure (arguably C:H), which is why this bug is best treated as a valuable stepping-stone for chaining (e.g., toward the sibling brute-force ATO and SSRF issues fixed in the same 1.5.5 release) rather than a standalone crisis. The source-code diff (PR #3422) confirms the mechanism and the fix, raising confidence in the root cause.

An unauthenticated network client sends malformed or edge-case requests to LightRAG API endpoints (document, graph, query, or ollama routes) to force an unhandled server-side exception, then reads the raw Python exception text returned in the JSON detail field. From the leaked filesystem paths, database host/port/user/database names and driver diagnostics - and, for URI-configured backends, connection strings with embedded credentials - the attacker maps the internal environment for follow-on attacks. No public exploit code was identified, but the low attack complexity and unauthenticated default make triggering errors trivial.