LightRAG Authentication Bypass via Hardcoded JWT Secret in API-Key-Only Deployments

Vulnerability Description

LightRAG contains a multi-stage authentication bypass affecting deployments using API-key-only authentication (LIGHTRAG_API_KEY set, AUTH_ACCOUNTS unset). The vulnerability stems from three compounding defects: (1) a hardcoded JWT secret (DEFAULT_TOKEN_SECRET) committed to the repository in lightrag/api/config.py:54, (2) unsafe fallback logic in lightrag/api/auth.py:28-38 that uses this default secret when AUTH_ACCOUNTS is not configured, and (3) unauthenticated endpoints (GET /auth-status, POST /login) in lightrag/api/lightrag_server.py:1140-1186 that expose authentication status without dependency checks. This represents a credential material exposure combined with broken authentication (OWASP A07:2021).

Proof-of-Concept Significance

The PoC demonstrates that this bypass requires no network reconnaissance—attackers can construct valid JWTs entirely offline using the public hardcoded secret. The attack surface is substantial: any LightRAG instance deployed with the documented API-key-only configuration is vulnerable without requiring specific versions, network timing, or service-side state queries. This significantly lowers the barrier to exploitation. The vulnerability is reliable and deterministic; successful JWT generation will always bypass the Depends(combined_auth) guard protecting all document operations (DELETE, POST/upload, cache clearing, queries).

Detection Guidance

Log Indicators:

• Requests to /auth-status or /login from unauthenticated sources (no X-API-Key header)
• JWT validation errors followed by successful requests with guest/default JWTs
• Successful document mutations (DELETE, POST) correlated with requests lacking valid X-API-Key headers
• Authentication fallback warnings in logs: look for patterns like "using default token secret" or "AUTH_ACCOUNTS not configured" in lightrag/api/auth.py warning messages

Network Signatures:

• Bearer tokens in Authorization headers where no prior valid authentication occurred
• Requests to /documents/clear_cache, /documents/delete, /documents/upload without corresponding API-key validation

Mitigation Steps

1. Immediate: Patch to a version that removes the hardcoded DEFAULT_TOKEN_SECRET and enforces explicit AUTH_ACCOUNTS configuration or generates a unique secret on startup
2. Configuration: Set AUTH_ACCOUNTS to a non-empty value, or ensure LIGHTRAG_API_KEY is properly enforced in reverse proxy/WAF rules
3. Credential Rotation: Rotate any LIGHTRAG_API_KEY values if API-key-only deployments are suspected to have been exposed
4. Access Control: Protect /auth-status and /login endpoints with authentication requirements; do not expose them unauthenticated
5. Audit: Review deployment configurations across all LightRAG instances to identify those using the vulnerable profile (LIGHTRAG_API_KEY + no AUTH_ACCOUNTS)

Risk Assessment

This vulnerability presents critical risk in the wild because: (a) the hardcoded secret is trivially discoverable via repository inspection, (b) the vulnerable deployment profile is officially documented and likely used by organizations following "quick-start" guidance, (c) exploitation requires no special privileges or timing, and (d) destructive capabilities (document deletion, cache clearing) enable data loss attacks. Threat actors with minimal sophistication can exploit this at scale. Organizations running LightRAG in the documented API-key-only configuration should assume active exposure and prioritize patching immediately.