Summary

Details

• 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)

• document routes.py — 2 (chunking-config validation)

except Exception as e:
  logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
  raise HTTPException(status code=500, detail=str(e))

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.

PoC

Step 1 — Filesystem path disclosure (default JSON storage)

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag storage/default/kv store full docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

{
  "detail": "[Errno 13] Permission denied: '/app/data/rag storage/default/kv store full docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

LIGHTRAG KV STORAGE=PGKVStorage
POSTGRES HOST=nonexistent-host-12345.example.com
POSTGRES PORT=5432
POSTGRES USER=lightrag
POSTGRES DATABASE=lightrag

{
  "detail": "[Errno -2] Name or service not known"
}

Impact

• Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
• Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

Suggested remediation

1. Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:

except Exception as e:
  logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
  raise HTTPException(status code=500, detail="Internal server error")

2. Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception handler(Exception)
async def unhandled exception handler(request, exc):
  logger.error(f"Unhandled exception: {exc!r}", exc info=True)
  return JSONResponse(status code=500, content={"detail": "Internal server error"})

3. Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)