LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection
Summary
When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.
This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).
Root cause
Three independent issues combine:
lightrag/api/config.py:54ships a hardcoded default JWT secret:DEFAULT_TOKEN_SECRET="lightr...key!"lightrag/api/auth.py:28-38falls back toDEFAULT_TOKEN_SECRETwith only a warning log whenAUTH_ACCOUNTSis not configured. The fix for CVE-2026-30762 only raises whenAUTH_ACCOUNTSis set, so the API-key-only path is silently vulnerable.lightrag/api/lightrag_server.py:1140-1186exposesGET /auth-statusandPOST /loginwithout any authentication dependency. In the API-key-only configuration,auth_handler.accountsis empty, and both endpoints unconditionally mint and return a signed guest JWT.lightrag/api/utils_api.py:214-216insidecombined_dependencyshort-circuits authorization on any valid guest token whenauth_configuredis false, before reaching theX-API-Keycheck on line 237:if not auth_configured and token_info.get("role") == "guest": return
Proof of concept (offline-minted token, zero server contact)
Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.
$ python3 -