CVE-2026-61740: LightRAG Auth Bypass Vulnerability

CVE-2026-61740 Overview

CVE-2026-61740 is an authentication bypass vulnerability [CWE-287] in LightRAG, a retrieval-augmented generation framework maintained by HKUDS. Versions prior to 1.5.4 allow remote unauthenticated attackers to bypass the X-API-Key protection when LIGHTRAG_API_KEY is configured but AUTH_ACCOUNTS is unset. The flaw resides in lightrag/api/auth.py, which falls back to a hardcoded DEFAULT_TOKEN_SECRET, and in combined_dependency within lightrag/api/utils_api.py, which accepts a valid guest JSON Web Token (JWT) before validating the API key. Attackers can mint guest tokens through /auth-status and /login endpoints and access protected functionality.

Critical Impact
Remote unauthenticated attackers can invoke document read, upload, deletion, graph mutation, and query endpoints on affected LightRAG deployments.

Affected Products

LightRAG (HKUDS) versions prior to 1.5.4
Deployments configured with LIGHTRAG_API_KEY set and AUTH_ACCOUNTS unset
LightRAG API server exposing endpoints guarded by combined_auth

Discovery Timeline

2026-07-15 - CVE-2026-61740 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-61740

Vulnerability Analysis

LightRAG exposes an authentication mode where operators set only LIGHTRAG_API_KEY without provisioning user accounts via AUTH_ACCOUNTS. In this API-key-only mode, the server intends to enforce the X-API-Key header as the sole authority. However, the combined_dependency function in lightrag/api/utils_api.py first validates any bearer JWT presented by the client. When it encounters a valid guest token, it returns early and skips the API key check entirely.

Attackers obtain a valid guest token through several paths. The /auth-status and /login endpoints mint guest JWTs on demand for unauthenticated callers. Alternatively, the lightrag/api/auth.py module falls back to a publicly known DEFAULT_TOKEN_SECRET when no secret is configured, enabling attackers to forge guest tokens directly.

Root Cause

The root cause is broken authentication logic that treats a guest role as sufficient credentials in a mode where guest roles should never authenticate. The reliance on a hardcoded default JWT signing secret compounds the flaw, allowing token forgery even without touching the auth endpoints.

Attack Vector

Exploitation requires only network access to the LightRAG API. An attacker requests /auth-status or /login to receive a guest JWT, then submits it as a bearer token to any endpoint protected by combined_auth. The server accepts the token and processes document uploads, deletions, graph mutations, and RAG queries without ever validating the configured API key.

python

                            logger.warning(f"Token auto-renew failed: {e}")
                # ========== End of Token Auto-Renewal Logic ==========

-                # Accept guest token if no auth is configured
+                # A token only authenticates when it matches the configured auth mode:
+                #   - password auth (AUTH_ACCOUNTS set): accept non-guest user tokens
+                #   - fully open (no AUTH_ACCOUNTS, no API key): accept guest tokens
+                # In the API-key-only profile (API key set, no AUTH_ACCOUNTS) a guest
+                # token must NOT authenticate: anyone can obtain one (via /auth-status,
+                # /login, or by signing it with the public default secret), so honoring
+                # it here would let a forged guest token bypass the X-API-Key check
+                # below (GHSA-f4vv-55c2-5789 / GHSA-xr5c-v5r6-c9f9). Instead, fall
+                # through so the API key stays mandatory in that mode.
                if not auth_configured and token_info.get("role") == "guest":
+                    if not api_key_configured:
+                        return
+                    # API-key-only mode: ignore the guest token; the X-API-Key check
+                    # below is the sole authority. Fall through (no return, no raise).
+                elif auth_configured and token_info.get("role") != "guest":
+                    # Accept non-guest token if password auth is configured
                    return
-                # Accept non-guest token if auth is configured
-                if auth_configured and token_info.get("role") != "guest":
-                    return

Source: GitHub Commit f7819aa

Detection Methods for CVE-2026-61740

Indicators of Compromise

Unauthenticated HTTP requests to /auth-status or /login from unexpected source addresses
Bearer JWTs with role: guest claims presented against sensitive endpoints such as /documents, /graphs, or /query
Absence of the X-API-Key header on requests that reach protected endpoints successfully
Unexpected document uploads, deletions, or knowledge graph mutations in LightRAG audit logs

Detection Strategies

Inspect reverse proxy or WAF logs for requests to /auth-status and /login followed by authenticated calls lacking X-API-Key
Decode JWTs seen in Authorization: Bearer headers and alert on the guest role when API-key-only mode is expected
Compare token signing keys against the known DEFAULT_TOKEN_SECRET value to identify forged tokens

Monitoring Recommendations

Enable structured request logging on the LightRAG API and forward events to a centralized SIEM
Baseline normal document and graph mutation volume, then alert on deviations from unauthenticated origins
Monitor egress from the LightRAG process for anomalous LLM or vector store queries triggered by attacker payloads

How to Mitigate CVE-2026-61740

Immediate Actions Required

Upgrade LightRAG to version 1.5.4 or later, which enforces the API key check in API-key-only mode
Restrict network access to the LightRAG API using firewall rules or reverse proxy allow-lists until patched
Rotate any LIGHTRAG_API_KEY values that may have been exposed while the vulnerable configuration was live
Review document stores and knowledge graphs for unauthorized modifications and restore from backups if tampering is found

Patch Information

The fix is available in LightRAG release v1.5.4 via commit f7819aa and pull request #3319. See the GHSA-f4vv-55c2-5789 advisory for full disclosure details.

Workarounds

Configure AUTH_ACCOUNTS with credentialed users so non-guest tokens are required, avoiding the vulnerable API-key-only mode
Set an explicit, high-entropy TOKEN_SECRET environment variable to prevent forgery using the hardcoded default
Place the LightRAG API behind an authenticating reverse proxy that enforces mutual TLS or an external identity provider

bash

# Configuration example: patch and harden LightRAG deployment
pip install --upgrade lightrag-hku==1.5.4

export LIGHTRAG_API_KEY="$(openssl rand -hex 32)"
export TOKEN_SECRET="$(openssl rand -hex 64)"
export AUTH_ACCOUNTS="admin:$(openssl rand -hex 16)"

# Restart the LightRAG API service to apply changes
systemctl restart lightrag-api