LightRAG CVE-2026-61740

Exploitation requires the LightRAG server to run in the API-key-only profile: LIGHTRAG_API_KEY (X-API-Key) is set while AUTH_ACCOUNTS is left unset, which makes auth_configured False and causes AuthHandler to fall back to the public DEFAULT_TOKEN_SECRET. Under that specific condition an unauthenticated remote attacker can obtain a guest JWT from the /auth-status or /login endpoints or sign one with the known default secret, and combined_dependency accepts it before checking the API key (AV:N/AC:L/PR:N/UI:N - no authentication, user interaction, or privileges needed). Limiting factors: deployments that set AUTH_ACCOUNTS (password auth) are NOT affected because non-guest tokens are required, and fully-open deployments (no API key at all) were already intentionally open; the flaw is strictly the API-key-only misconfiguration window, and overriding TOKEN_SECRET away from the default reduces the token-forgery path.

This is a genuine high-priority issue rather than a high-CVSS-but-low-real-risk case, but its scope is gated by deployment mode. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L) scores 9.3 and is internally consistent with the description: network reachable, low complexity, no privileges, no user interaction, high confidentiality and integrity impact, low availability impact. Exploitation is trivial where the vulnerable profile is in use - an attacker only needs to mint or fetch a guest token and reach the API - which would normally map to a high EPSS, but no EPSS score, KEV entry, or public exploit was provided in the input. The key limiting signal, which the raw score does not capture, is configuration dependence: only the API-key-only profile (LIGHTRAG_API_KEY set AND AUTH_ACCOUNTS unset) is affected; fully-open and password-auth deployments are not. No CISA KEV listing and no EPSS/SSVC data were provided, so real-world exploitation breadth cannot be confirmed from the input and should be treated as plausible-but-unmeasured. Note the CVSS models VA:L (availability low) even though document/graph deletion could arguably justify a higher availability impact - verify against your data-criticality.

An attacker discovers an internet-exposed LightRAG server running in the API-key-only profile, sends an unauthenticated request to /auth-status or /login to obtain a guest JWT (or forges one locally by signing with the known DEFAULT_TOKEN_SECRET), and presents that token to combined_auth-guarded endpoints. Without ever supplying the operator's X-API-Key, they read, upload, and delete indexed documents, mutate the knowledge graph, and run queries. Given AV:N/AC:L/PR:N/UI:N this requires only network reachability and a single scripted request; no public exploit is identified at time of analysis, though the vendor's regression test shows the forgery is trivial.