What is the CVSS score of CVE-2026-39413?

CVE-2026-39413 has a CVSS 3.1 base score of 4.2 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-39413?

Yes, a patch is available for CVE-2026-39413. Update the affected software to the latest version immediately.

Python CVE-2026-39413

EUVD-2026-20601 MEDIUM

Improper Verification of Cryptographic Signature (CWE-347)

2026-04-08 https://github.com/HKUDS/LightRAG

GHSA-8ffj-4hx4-9pgf

Python Jwt Attack Authentication Bypass

4.2

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

4.2 MEDIUM

AV:N/AC:H/PR:H/UI:R/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:H/PR:H/UI:R/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

EUVD ID Assigned

Apr 08, 2026 - 00:30 euvd

EUVD-2026-20601

Analysis Generated

Apr 08, 2026 - 00:30 vuln.today

Patch released

Apr 08, 2026 - 00:30 nvd

Patch available

CVE Published

Apr 08, 2026 - 00:17 nvd

MEDIUM 4.2

DescriptionGitHub Advisory

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'])

AnalysisAI

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.

Technical ContextAI

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.

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.