Skip to main content

AI / ML CVE-2026-30762

HIGH
Improper Authentication (CWE-287)
2026-04-04 https://github.com/HKUDS/LightRAG GHSA-mcww-4hxq-hfr3
7.5
CVSS 3.1 · GitHub Advisory
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Discover default JWT secret in source code
  2. Delivery
    Forge valid JWT token using PyJWT library
  3. Exploit
    Send forged token in API request
  4. Execution
    Bypass authentication checks
  5. Impact
    Access protected endpoints as authenticated user

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK

2 techniques across 2 tactics: Defense Evasion, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

LightRAG v1.4.10 with AUTH_ACCOUNTS configured but TOKEN_SECRET environment variable not set. Unauthenticated remote attacker forges JWT tokens using publicly known default secret 'lightrag-jwt-default-secret' to access protected endpoints. No user interaction required.

Impact

Real-world risk is HIGH for exposed installations despite moderate CVSS scoring. The CVSS vector AV:N/AC:L/PR:N/UI:N indicates network-accessible exploitation with low complexity and no authentication required, making this trivially exploitable. However, the confidentiality-only impact (C:H/I:N/A:N) limits the score to 7.5. The attack requires the specific misconfiguration where AUTH_ACCOUNTS is set but TOKEN_SECRET is not, which may be common in quick deployments or development environments exposed to networks. No EPSS score is available, and this CVE is not in CISA KEV, indicating no confirmed active exploitation. However, the barrier to exploitation is extremely low post-disclosure since the default secret is now public knowledge and JWT forging requires only basic Python skills. The GitHub Security Advisory publication significantly increases exploitation likelihood. Organizations using LightRAG with authentication enabled should treat this as an immediate priority regardless of the moderate CVSS score, as the gap between theoretical and practical exploitability is minimal for internet-facing instances.

Exploit ScenarioDerived

An attacker discovers a publicly accessible LightRAG instance at api.example.com running with AUTH_ACCOUNTS configured. Using the publicly disclosed default secret 'lightrag-jwt-default-secret', the attacker runs a simple Python script with PyJWT to forge a token containing admin-level claims: jwt.encode({'sub': 'admin', 'role': 'admin', 'exp': time.time() + 3600}, 'lightrag-jwt-default-secret', algorithm='HS256'). They submit API requests with the Authorization: Bearer header containing this forged token, successfully authenticating as an administrator without knowing any legitimate credentials. The attacker can now access protected RAG query endpoints, exfiltrate indexed document data, or manipulate knowledge graph contents. The attack requires only network access and basic scripting knowledge, with no complex exploitation techniques or privilege escalation needed.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Apr 04, 2026

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.

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.

Affected Packages

pypi lightrag-hku fix: 1.4.13

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when AI / ML gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

GitHub Advisory PRIMARY 7.5 HIGH
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

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

2
Patch released
Apr 04, 2026 - 08:30 nvd
Patch available
CVE Published
Apr 04, 2026 - 06:14 nvd
HIGH 7.5

DescriptionGitHub 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:

  1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
  2. Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
  3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
  4. 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

Executive ViewAI

Why It Matters

LightRAG versions 1.4.10 with authentication enabled but default JWT secret unchanged allow unauthenticated attackers to forge authentication tokens and access protected API endpoints, potentially exposing sensitive data without requiring valid credentials. Organizations using LightRAG should immediately verify their TOKEN_SECRET configuration, as this vulnerability bypasses authentication controls entirely in affected deployments. This represents a critical authentication failure that could enable unauthorized data access or system manipulation depending on API endpoint functionality.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Immediately set TOKEN_SECRET environment variable to a cryptographically random value minimum 32 characters; (2) Restrict network access to LightRAG API endpoints via firewall or WAF rules to trusted internal networks only; (3) Invalidate and reissue all JWT tokens after TOKEN_SECRET configuration; (4) Implement API authentication monitoring and anomaly detection for suspicious token patterns; (5) Consider deploying LightRAG behind a reverse proxy with additional authentication layer until patch is available.

Threat Intelligence Overview

EPSS Score
0.1%
Top 69% exploitable
Threat Intel
1
1 source
Data Quality
3 sources
Confidence: Low

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Affected Products (CPE)GitHub Advisory

pkg:pip/lightrag-hku
CVE-2026-23744 CRITICAL POC
9.8 Jan 16

MCPJam Inspector versions 1.4.2 and earlier allow unauthenticated remote code execution through missing authentication i

CVE-2026-0768 CRITICAL POC
9.8 Jan 23

Langflow has a code injection vulnerability in the code component (EPSS 2.6%) enabling remote code execution through the

CVE-2026-0769 CRITICAL POC
9.8 Jan 23

Langflow has an eval injection in eval_custom_component_code (EPSS 2.0%) enabling remote code execution through crafted

CVE-2024-8859 HIGH POC
7.5 Mar 20

A path traversal vulnerability exists in mlflow/mlflow version 2.15.1. Rated high severity (CVSS 7.5), this vulnerabilit

CVE-2026-27966 CRITICAL POC
9.8 Feb 26

Code injection in Langflow CSV Agent node before 1.8.0. The node hardcodes allow_dangerous_code=True, enabling arbitrary

CVE-2026-27597 CRITICAL POC
10.0 Feb 25

Sandbox escape in Enclave JavaScript sandbox before 2.11.1. Enclave is designed for safe AI agent code execution — the e

CVE-2026-22686 CRITICAL POC
10.0 Jan 14

enclave-vm JavaScript sandbox (before 2.7.0) has a critical sandbox escape. When a tool invocation fails, a host-side Er

CVE-2025-2828 CRITICAL POC
10.0 Jun 23

A remote code execution vulnerability in langchain-ai/langchain (CVSS 10.0). Risk factors: public PoC available. Vendor

CVE-2026-1470 CRITICAL POC
9.9 Jan 27

n8n has a fifth critical RCE vulnerability (CVSS 9.9) in the Expression evaluator, enabling code execution through craft

CVE-2026-24770 CRITICAL POC
9.8 Jan 27

Path traversal vulnerability in RAGFlow RAG engine version 0.23.1 allows unauthenticated attackers to read arbitrary fil

CVE-2026-22688 CRITICAL POC
9.9 Jan 10

WeKnora LLM framework (before 0.2.5) allows authenticated users to inject MCP stdio commands that the server executes as

CVE-2026-30861 CRITICAL POC
9.9 Mar 07

OS command injection in WeKnora from version 0.2.5 allows authenticated users to execute arbitrary system commands. CVSS

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy