lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses
Medium5.3CVE-2026-85709 · Published Sep 22, 2026
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| lightrag-hku PyPI | < 1.5.5 | 1.5.5 |
Details and references
### Summary The LightRAG API server passes raw Python exception messages directly into HTTP error responses across 30+ error handlers in every router. When combined with the default unauthenticated configuration (see companion report on CWE-306), any network-reachable client can trigger exceptions whose raw text discloses internal infrastructure , server filesystem paths, database host/port/user, LLM provider error details, and Python library internals. No global exception handler sanitizes error messages before they reach the client. ### Details Throughout the API route handlers, exceptions are caught and their string representation is returned verbatim via `detail=str(e)` / `detail=str(exc)` (and f-string variants such as `detail=f"...: {str(e)}"`). This occurs in every router file. Location breakdown on the current `main` branch: **HTTP 500 , raw exception passthrough (`except Exception as e`):** - `document_routes.py` , 13 - `graph_routes.py` , 12 (mix of `detail=f"...{str(e)}"` and `detail=error_msg`) - `query_routes.py` , 3 - `ollama_api.py` , 2 - `lightrag_server.py` , 1 (health endpoint) **HTTP 422 , raw exception passthrough (`except ValueError as exc`):** - `document_routes.py` , 2 (chunking-config validation) **Total: ~33 raw-exception-to-HTTP-response locations.** The only pre-existing custom exception handler in `lightrag_server.py` is specific to `RequestValidationError` for `/query/data`; it does not cover the generic `Exception` handlers in route code. Example pattern (`document_routes.py`, upload handler): ```python except Exception as e: logger.error(f"Error /documents/upload: {file.filename}: {str(e)}") raise HTTPException(status_code=500, detail=str(e)) ``` **Categories of sensitive information that can leak through these responses:** 1. **Server filesystem paths.** File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. `[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'`), aiding path-traversal or targeted attacks. *(Verified , see PoC Step 1.)* 2. **Database host / port / user / database name.** Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach , e.g. asyncpg raises `password authentication failed for user "lightrag"` (username) or a socket error naming the unreachable host and port. **Note on credentials:** the PostgreSQL backend uses `asyncpg`, which is built from keyword parameters and does **not** echo the password in its exception strings , so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with `AsyncMongoClient(MONGO_URI, ...)`, and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (`mongodb://user:password@host:port/`). The leak surface is therefore backend- and error-type-dependent. 3. **LLM provider error details.** Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment. 4. **Python library internals.** Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version. 5. **Configuration details.** Errors during configuration/parsing may reveal storage backend types and other configuration values. The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials. ### PoC Tested on a clean checkout with the `[api]` extras installed and the server run via `lightrag-server`. #### Step 1 , Filesystem path disclosure (default JSON storage) With the default storage backend, a file-permission error is returned verbatim: ```b
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-209
- Also known as
- CVE-2026-85709
- github.com/HKUDS/LightRAG/security/advisories/GHSA-hrmj-7rvj-4hg8
- nvd.nist.gov/vuln/detail/CVE-2026-85709
- github.com/HKUDS/LightRAG/pull/3422
- github.com/HKUDS/LightRAG/commit/4d90a0eb35d40b45f3a9045e308ec126897a3364
- github.com/HKUDS/LightRAG/commit/dcab315d7dc1eea682e9b2c4fcb1b06474484c47
- github.com/HKUDS/LightRAG
- github.com/HKUDS/LightRAG/releases/tag/v1.5.5
More lightrag advisories
All| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Sep 22 | lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function CVE-2026-85725Medium5.9fixed in 1.5.5 | Medium5.9 | 1.5.5 |
| Sep 22 | lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks CVE-2026-85734Critical9.1fixed in 1.5.5 | Critical9.1 | 1.5.5 |
| Sep 22 | lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard CVE-2026-85740High7.1fixed in 1.5.5 | High7.1 | 1.5.5 |
| Sep 22 | lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content CVE-2026-86062Medium6.1fixed in 1.5.5 | Medium6.1 | 1.5.5 |
| Jul 20 | LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection CVE-2026-61740Criticalfixed in 1.5.4 | Critical | 1.5.4 |
| Jul 20 | LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests CVE-2026-61736Critical9.3fixed in 1.5.4 | Critical9.3 | 1.5.4 |