AI / ML CVE-2026-30762
HIGH
GHSA-mcww-4hxq-hfr3
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary: The file lightrag/api/config.py (line 397) uses a default JWT secret "lightrag-jwt-default-secret" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.
Reproduction:
- Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
- Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
- Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
- Access is granted without valid credentials
Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.
--- Venkata Avinash Taduturi taduturivenkata@gmail.com
AnalysisAI
LightRAG's JWT authentication can be bypassed via a hardcoded default secret 'lightrag-jwt-default-secret' when TOKEN_SECRET is not configured. Unauthenticated attackers can forge valid tokens to access protected API endpoints in installations running v1.4.10 with AUTH_ACCOUNTS enabled but TOKEN_SECRET unset. CVSS 7.5 (High) reflects network-accessible confidentiality breach with no authentication required. No public exploit identified at time of analysis, though the hardcoded secret is publicly documented in the vulnerability disclosure. EPSS data not available for this CVE.
Technical ContextAI
LightRAG (pkg:pip/lightrag-hku) implements JWT-based authentication in its API layer using the PyJWT library. The vulnerability stems from CWE-287 (Improper Authentication) where the configuration file lightrag/api/config.py falls back to a hardcoded default secret 'lightrag-jwt-default-secret' when the TOKEN_SECRET environment variable is not provided. The AuthHandler class in lightrag/api/auth.py uses this secret with HMAC-SHA256 signing to generate and validate JWTs. Because the default secret is identical across all installations and now publicly disclosed, any attacker can use standard JWT libraries to sign arbitrary tokens with claims like admin roles. This is a classic example of insecure defaults where optional security configuration fails open rather than closed, violating secure-by-default principles. The JWT specification itself (RFC 7519) is secure when properly implemented with strong secrets, but the application-level implementation failed to enforce secret uniqueness.
RemediationAI
Immediately set a strong, randomly generated TOKEN_SECRET environment variable for all LightRAG deployments with authentication enabled. Generate a secure secret using a cryptographically secure random generator such as Python's secrets.token_urlsafe(32) or equivalent. Restart the LightRAG API server after setting the environment variable to ensure the new secret is loaded. Review access logs for any suspicious authentication attempts using timestamps that predate this remediation, as previously issued tokens signed with the default secret should be considered compromised. Rotate all user credentials as a precautionary measure if the system was internet-accessible with the default secret. The vendor's suggested fix requires TOKEN_SECRET to be explicitly configured when AUTH_ACCOUNTS is enabled, causing the server to refuse startup if missing. Monitor the GitHub advisory at https://github.com/HKUDS/LightRAG/security/advisories/GHSA-mcww-4hxq-hfr3 for patch release information. Upstream fix available via GitHub advisory; specific patched version release details should be confirmed from the vendor repository. Until a version with mandatory secret enforcement is released, manual configuration validation is required.
MCPJam Inspector versions 1.4.2 and earlier allow unauthenticated remote code execution through missing authentication i
A path traversal vulnerability exists in mlflow/mlflow version 2.15.1. Rated high severity (CVSS 7.5), this vulnerabilit
Code injection in Langflow CSV Agent node before 1.8.0. The node hardcodes allow_dangerous_code=True, enabling arbitrary
Langflow has a third RCE vulnerability via exec_globals (EPSS 10.0%) allowing inclusion of untrusted code that executes
Sandbox escape in Enclave JavaScript sandbox before 2.11.1. Enclave is designed for safe AI agent code execution — the e
enclave-vm JavaScript sandbox (before 2.7.0) has a critical sandbox escape. When a tool invocation fails, a host-side Er
A remote code execution vulnerability in langchain-ai/langchain (CVSS 10.0). Risk factors: public PoC available. Vendor
n8n has a fifth critical RCE vulnerability (CVSS 9.9) in the Expression evaluator, enabling code execution through craft
Path traversal vulnerability in RAGFlow RAG engine version 0.23.1 allows unauthenticated attackers to read arbitrary fil
WeKnora LLM framework (before 0.2.5) allows authenticated users to inject MCP stdio commands that the server executes as
OS command injection in WeKnora from version 0.2.5 allows authenticated users to execute arbitrary system commands. CVSS
Shell command injection in Nuclio serverless framework before 1.15.20. PoC and patch available.
Same weakness CWE-287 – Improper Authentication
View allShare
External POC / Exploit Code
Leaving vuln.today