Skip to main content

Python EUVDEUVD-2026-20601

| CVE-2026-39413 MEDIUM
Improper Verification of Cryptographic Signature (CWE-347)
2026-04-08 https://github.com/HKUDS/LightRAG GHSA-8ffj-4hx4-9pgf
6.5
CVSS 3.1 · NVD
View

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
Impact

CVSS 4.2 with vector AV:N/AC:H/PR:H/UI:R indicates the attack requires network access (exploitable remotely), high attack complexity (specific conditions needed), high privilege level (authenticated user required), and user interaction. However, this CVSS rating appears inconsistent with the actual threat profile: the vulnerability enables complete authentication bypass without valid credentials, which contradicts the PR:H (privileged user required) component. The true risk is substantially higher than the CVSS score suggests. The proof-of-concept code is publicly available, lowering barrier to exploitation. No EPSS or KEV (CISA Known Exploited Vulnerabilities) status provided; however, the straightforward PoC and authentication bypass nature indicate this is a high-priority real-world risk despite the moderate base score. The vulnerability is not dependent on social engineering (despite UI:R in the vector) - the PoC shows direct API exploitation via curl. SSVC perspective: this has confirmed exploitation feasibility (PoC), high automatable impact (full API access), and human-initiated technical impact (system compromise); remediation is available and vendor-supported.

Exploit ScenarioDerived

An attacker with network access to the LightRAG API constructs a JWT token with header 'alg': 'none' and payload claims for an administrative user (e.g., 'sub': 'admin', 'role': 'admin') with an arbitrary or distant expiration time. The attacker sends this unsigned token in an HTTP Authorization header (Bearer token) to any protected endpoint. The validate_token() method in lightrag/api/auth.py accepts the token as valid because it does not explicitly reject the 'none' algorithm, and the unsigned payload is decoded without signature verification. The attacker then gains full administrative access to the LightRAG API, including the ability to read sensitive data, modify configurations, or pivot to connected systems. The publicly available PoC demonstrates this with a curl command, making the attack reproducible by any attacker with basic HTTP knowledge.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.0% exploitation probability (EPSS)

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

Alert me

AnalysisAIv1 – Apr 08, 2026

LightRAG API authentication can be bypassed via JWT algorithm confusion attack, where an attacker forges tokens by specifying 'alg': 'none' in the JWT header to impersonate any user including administrators. The vulnerability exists in the validate_token() method in lightrag/api/auth.py (line 128), which accepts the unsigned 'none' algorithm despite not explicitly permitting it, allowing unauthenticated remote attackers to gain unauthorized access to protected resources. Publicly available proof-of-concept code demonstrates the attack; vendor has released a patch addressing the root cause of improper algorithm validation.

RemediationAI

Upgrade LightRAG to the patched version released by the vendor; the fix is available in commit 728f2e54509d93e0a44f929c7f83f2c88d6d291b at https://github.com/HKUDS/LightRAG. The patch explicitly excludes the 'none' algorithm and restricts jwt.decode() to explicitly approved algorithms (e.g., HS256) rather than allowing any algorithm specified in the token header. Immediately update the lightrag-hku Python package to the latest available version from PyPI. For environments unable to patch immediately, implement a temporary mitigation by validating that the JWT header does not contain 'alg': 'none' before passing tokens to jwt.decode(); however, this is not a complete fix and patching should be prioritized. Review all historical API access logs to identify if forged tokens with 'alg': 'none' were used to gain unauthorized access, and rotate any exposed credentials or session tokens. Refer to the vendor advisory at https://github.com/advisories/GHSA-8ffj-4hx4-9pgf for additional context and validation steps.

Affected VersionsENISA

LightRAG < 1.4.14

Affected Packages

pypi lightrag-hku fix: 1.4.14
euvd lightrag fix: 1.4.14

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in pypi, euvd

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

Technical ContextAI · show details

The vulnerability stems from a JWT algorithm confusion flaw (CWE-347) in how the LightRAG API's PyJWT library integration validates token authenticity. The vulnerable code calls jwt.decode(token, self.secret, algorithms=[self.algorithm]) without explicitly excluding the 'none' algorithm, which is a no-signature variant that some JWT implementations process when present in the token header. The PyJWT library documentation advises explicitly specifying allowed algorithms and excluding 'none' to prevent this attack class. The issue affects the Python package lightrag-hku (CPE: pkg:pip/lightrag-hku), which is deployed as the LightRAG API service. When an attacker crafts a JWT with 'alg': 'none' and a properly structured payload containing forged claims (e.g., 'sub': 'admin', 'role': 'admin'), the validation method accepts it as valid without cryptographic signature verification, enabling arbitrary user impersonation.

Know when Python 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

NVD PRIMARY 6.5 MEDIUM
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

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

Lifecycle Timeline

3
CVSS changed
Jul 24, 2026 - 21:22 NVD
4.2 (MEDIUM) 6.5 (MEDIUM)
Patch released
Apr 08, 2026 - 00:30 nvd
Patch available
CVE Published
Apr 08, 2026 - 00:17 nvd
MEDIUM 4.2

DescriptionNVD

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

python
payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

json
{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

bash
curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

python
allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

python
payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Threat Intelligence Overview

EPSS Score
0.0%
Top 94% exploitable
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub

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 MEDIUM
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.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
Poc
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Total

Priority Score

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

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

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