CVE-2026-30762: 
Python vulnerability analysis and mitigation

CVE-2026-30762 is a hardcoded JWT signing secret vulnerability in LightRAG (pip package lightrag-hku) that allows unauthenticated attackers to forge valid JWT tokens and bypass authentication on any protected API endpoint. The vulnerability affects all versions up to and including 1.4.12, with version 1.4.13 containing the fix. It was discovered by Venkata Avinash Taduturi, published to the GitHub Advisory Database on April 4, 2026, and assigned GHSA-mcww-4hxq-hfr3. The CVSS v3.1 base score is 7.5 (High) (GitHub Advisory).

The root cause is the use of a hardcoded default JWT signing secret ("lightrag-jwt-default-secret") in lightrag/api/config.py (line 397), which is applied when the TOKEN_SECRET environment variable is not explicitly set (CWE-287: Improper Authentication). The AuthHandler class in lightrag/api/auth.py (lines 24–25) uses this secret for both signing and verifying HS256 JWT tokens, meaning any attacker who knows the publicly documented default secret can craft a cryptographically valid token. Because the secret is embedded in the source code and publicly known via the repository, no brute-force or cryptographic attack is required — exploitation is trivially achievable with a standard JWT library such as PyJWT (GitHub Advisory, HKUDS Advisory).

Successful exploitation grants an unauthenticated remote attacker full access to all protected API endpoints in a LightRAG deployment where AUTH_ACCOUNTS is configured but TOKEN_SECRET is not explicitly set. The primary impact is a high confidentiality loss — attackers can read, query, and exfiltrate all data managed by the LightRAG knowledge graph API, including potentially sensitive documents and embeddings ingested by the application. Integrity and availability are not directly impacted per the CVSS assessment, though unauthorized API access could enable further abuse depending on the deployment context (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible LightRAG API instances (e.g., via Shodan, Censys, or internal network scanning) running lightrag-hku version ≤ 1.4.12 with AUTH_ACCOUNTS configured.
2. Verify default secret in use: Confirm that the target instance was not started with a custom TOKEN_SECRET environment variable — this is the default configuration for many deployments.
3. Forge a JWT token: Using PyJWT or any JWT library, craft a token signed with the known default secret:

   import jwt
   token = jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")

4. Send authenticated request: Include the forged token in the Authorization header of an HTTP request to any protected endpoint:

   GET /api/protected-endpoint HTTP/1.1
   Host: <target>
   Authorization: Bearer <forged_token>

5. Access granted: The server validates the token signature using the same hardcoded secret and grants full access to the protected endpoint without requiring valid credentials (GitHub Advisory, HKUDS Advisory).

• Network: Unexpected or anomalous HTTP requests to protected LightRAG API endpoints from IP addresses with no prior authentication history; requests bearing Authorization: Bearer headers from unauthenticated or unknown clients.
• Logs: API access logs showing successful authenticated requests to protected endpoints where no corresponding login event exists; JWT tokens in logs with the sub claim set to admin or other privileged values without a matching login flow.
• Application: JWT tokens signed with the algorithm HS256 and verifiable using the secret lightrag-jwt-default-secret appearing in request headers — these can be decoded and checked with any JWT debugger (e.g., jwt.io) to confirm use of the default secret.

Upgrade lightrag-hku to version 1.4.13 or later, which contains the patch for this vulnerability (GitHub Advisory). As an immediate workaround for deployments that cannot upgrade, explicitly set the TOKEN_SECRET environment variable to a strong, randomly generated secret before starting the API server — this overrides the insecure default. Additionally, restrict network access to the LightRAG API to trusted hosts only, reducing the attack surface until a patch can be applied. The suggested long-term fix from the reporter is to require TOKEN_SECRET to be set whenever AUTH_ACCOUNTS is configured, and to refuse server startup if this condition is not met (HKUDS Advisory).