LightRAG vulnerabilities

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, the POST /login endpoint in lightrag/api/lightrag_server.py does not impose a rate limit, account lockout, delay, or counter for failed authentication attempts. A network attacker can submit password guesses at full request speed until a valid account password is found.

LightRAG through version 1.5.4 has an API server that 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.

In LightRAG prior to 1.5.4, when LIGHTRAG_API_KEY is set but AUTH_ACCOUNTS is unset, X-API-Key protection can be bypassed. The system falls back to a hardcoded DEFAULT_TOKEN_SECRET, and /auth-status and /login can mint guest JWTs that are accepted before checking the API key. A remote unauthenticated attacker can call guarded endpoints, including document read, upload, deletion, graph mutation, and query endpoints.

LightRAG before version 1.5.4 defaults to CORS_ORIGINS=* combined with allow_credentials=True, causing Starlette CORSMiddleware to whitelist every origin for credentialed cross-origin requests. An attacker can make authenticated API requests from a malicious website, exfiltrating documents and knowledge graph data or performing destructive actions.

LightRAG prior to 1.5.5 renders answer and thinking content with react-markdown, rehypeRaw, and skipHtml=false without an HTML sanitizer. An attacker who can add a document can store raw HTML that is returned through the query path and rendered as active content, enabling arbitrary JavaScript execution via elements such as iframe srcdoc. The script runs in the LightRAG WebUI origin and can read the API token from localStorage and perform API actions as the victim.

LightRAG prior to 1.5.5 contains a vulnerability in the Markdown parser that allows fetching resources with internal IPv4 addresses using NAT64 translators, potentially leading to unauthorized access to internal resources.

LightRAG prior to 1.5.5 has verify_password in lightrag/api/passwords.py comparing plaintext AUTH_ACCOUNTS password values with Python's == operator. The comparison can return after the first mismatching byte, creating response-time differences based on password length and matching prefixes. A network attacker with sufficiently low-latency access can repeatedly query /login and use the timing oracle to recover a plaintext-configured password character by character. Deployments using bcrypt-prefixed password values are not affected by this comparison path.

LightRAG prior to 1.5.5 returns raw Python exception text from error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py. The detail=str(e), detail=str(exc), and equivalent formatted-message paths expose server filesystem paths, database host, port, user, and database names, language-model provider diagnostics, configuration details, and Python library internals to a network client that can trigger an error. The default unauthenticated configuration makes those responses reachable without credentials.

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