[Security] Hardcoded JWT Fallback Secret Enables Authentication Bypass

[28Hus]

Hardcoded JWT Fallback Secret Enables Authentication Bypass

Hello maintainers,

Could you please review a conditional authentication bypass in the LightRAG API?

Impact

When AUTH_ACCOUNTS is configured but TOKEN_SECRET is omitted, the API uses the publicly known signing key lightrag-jwt-default-secret. An unauthenticated remote attacker can sign a non-guest JWT and access protected endpoints without knowing any configured account password. This includes document status and query routes.

The impact is conditional: AUTH_ACCOUNTS defaults to an empty value, which disables JWT account authentication. This report concerns deployments that enable account authentication but leave the signing secret unset.

Evidence

• config.py#L288-L293 uses the hardcoded fallback lightrag-jwt-default-secret and defaults to HS256.
• auth.py#L23-L34 loads the configured accounts and signing secret. auth.py#L64-L103 signs and validates JWTs with that secret.
• utils_api.py#L104-L124 accepts any valid non-guest token when account authentication is enabled; it does not verify the token subject against the configured accounts.
• query_routes.py#L129-L132 and document_routes.py#L1265-L1270 protect routes with this authentication dependency.

Reproduction

On a local instance you control, configure a non-empty AUTH_ACCOUNTS and leave TOKEN_SECRET unset:

import time
import jwt
import requests

base_url = "http://127.0.0.1:9621"
token = jwt.encode(
    {
        "sub": "attacker",
        "role": "user",
        "metadata": {},
        "exp": int(time.time()) + 300,
    },
    "lightrag-jwt-default-secret",
    algorithm="HS256",
)

response = requests.get(
    f"{base_url}/documents",
    headers={"Authorization": f"Bearer {token}"},
)
print(response.status_code, response.text)

Expected result: a request without credentials is rejected, while the forged token is accepted. This PoC was not executed; it follows the code paths linked above.

Remediation

Remove the insecure fallback. Require a strong, randomly generated TOKEN_SECRET when AUTH_ACCOUNTS is set, and fail startup if it is missing. Rotate the signing key on affected deployments to invalidate forged tokens.

Related works

• Arcade MCP, CVE-2025-66454: a hardcoded JWT worker secret enabled authentication bypass.
• Bambuddy, CVE-2026-25505: hardcoded JWT secret and API authentication issues.
• AstrBot, CVE-2025-55449: hardcoded JWT signing keys enabled authentication bypass, leading to plugin-based RCE.
• Apache Superset, CVE-2023-27524: an unchanged default SECRET_KEY enabled session-validation attacks.
• Label Studio, CVE-2023-43791: a hardcoded Django SECRET_KEY enabled session forgery; the reported impact involved chaining another vulnerability.
• Redash, CVE-2021-41192: a shared default cookie secret enabled forged sessions.
• PPress, CVE-2025-54761: privilege escalation via a crafted session cookie; this is an adjacent session-forgery case.
• WeRSS, CVE-2026-2215: an unreviewed advisory describes a JWT handler falling back to a default cryptographic key; affected versions and source are listed as unknown.

This report is part of my ongoing research. If you have any questions, please feel free to mention me here at any time. I’d be glad to contribute, however modestly, to improving the security of your project.