CVE-2026-85709

### 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/