Skip to content
lightragGHSA-hrmj-7rvj-4hg8

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

Medium5.3CVE-2026-85709 · Published Sep 22, 2026

GitHub advisory

Affected versions

PackageAffectedFixed in
lightrag-hku
PyPI
< 1.5.51.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

More lightrag advisories

All

Critical advisories by email

Wednesdays: the week’s critical and high advisories in the AI and data stack, with the fixed versions. Only in weeks that have some.

Double opt-in. Unsubscribe any time.