EUVD-2026-54644Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
The insecure 0.0.0.0 bind with no auth is the shipped default, so PR:N and AC:L hold, with full document/graph read-write giving C:H/I:H and pipeline/cache/LLM abuse giving A:H.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
5DescriptionCVE.org
LightRAG provides simple and fast retrieval-augmented generation. Through version 1.5.4, the LightRAG API server binds to all network interfaces with authentication disabled by default, allowing an unauthenticated network attacker to read indexed document content, upload or delete documents, modify the knowledge graph, cancel pipelines, clear caches, and consume LLM resources. This issue is mitigated in version 1.5.5rc1.
AnalysisAI
Missing authentication in the LightRAG API server (HKUDS/LightRAG) through version 1.5.4 exposes every management endpoint to unauthenticated network attackers, because the server binds to 0.0.0.0 by default while authentication is off unless explicitly configured. Any attacker with network reach can read indexed document content, upload or delete documents, rewrite the knowledge graph, cancel ingestion pipelines, clear caches, and consume LLM/API credits. No public exploit identified at time of analysis, but exploitation is trivial via a single unauthenticated HTTP request, and the fix in 1.5.5rc1 is largely a hardening/warning change rather than an enforced secure default, so operator action is still required.
Technical ContextAI
LightRAG is a retrieval-augmented generation (RAG) framework that ships a FastAPI-based API server plus WebUI and an Ollama-compatible /api/* interface for chat and generation. The root cause is CWE-306 (Missing Authentication for Critical Function): the server defaults HOST to 0.0.0.0 (all interfaces) but leaves authentication disabled unless LIGHTRAG_API_KEY, or AUTH_ACCOUNTS together with TOKEN_SECRET, are set in .env. Compounding this, even when auth is enabled the default WHITELIST_PATHS exempts the entire /api/* prefix (to mirror Ollama's own unauthenticated behavior), leaving the LLM-invoking chat/generate routes open. The referenced commit adds a whitelist_exposes_api_routes() helper and a splash-screen warning, and documents that operators must narrow WHITELIST_PATHS to /health and bind to 127.0.0.1 or set an API key before exposing the server to a network.
RemediationAI
Upgrade to LightRAG 1.5.5rc1 or later per GHSA-mmg5-8x8q-v934 (https://github.com/HKUDS/LightRAG/security/advisories/GHSA-mmg5-8x8q-v934); note this is a release candidate and, per commit 0bd1024, chiefly adds warnings and documentation rather than a secure-by-default flip, so you must also configure authentication yourself. Set LIGHTRAG_API_KEY (or AUTH_ACCOUNTS together with a non-default TOKEN_SECRET, without which the server refuses to start) in .env before exposing the server. Because the default WHITELIST_PATHS exempts the Ollama-compatible /api/* routes (/api/chat, /api/generate, etc.) even when auth is enabled, set WHITELIST_PATHS=/health to require authentication on those LLM-invoking routes too - the trade-off is that Ollama clients must then send the API key. If network exposure is not needed, bind to 127.0.0.1 (HOST=127.0.0.1), which removes remote access entirely; for containers, publish the port only to a trusted interface or place the service behind an authenticating reverse proxy or network ACL. Until upgraded and authenticated, restrict inbound access to the API port at the firewall.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today