Lightrag
Monthly
Server-side request forgery (CWE-918) in LightRAG before 1.5.5 lets an authenticated caller who can upload a Markdown or textpack document point an external image URL at an IPv6 transition-wrapper literal (NAT64 well-known prefix 64:ff9b::/96 or an IPv4-compatible ::a.b.c.d form) that embeds a loopback, RFC1918, CGNAT, or cloud-metadata IPv4 address, causing the parser's image download to fetch the internal resource and ingest its body. The guard in lightrag/parser/markdown/parser.py evaluated only the literal address with ipaddress.is_global, which classifies these wrappers as globally routable, so the embedded internal target was never checked. Exploitation is conditional (AC:H): the deployment must have compatible NAT64/DNS64 routing for the wrapper to be delivered to the embedded target, which is why the assessed vector is AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). The issue is fixed in v1.5.5.
Unthrottled password guessing against the LightRAG POST /login endpoint allows an unauthenticated remote attacker to submit credential attempts at full request speed until a valid account password is recovered, after which the attacker gains authenticated access to documents, the knowledge graph, and administrative operations. Versions prior to 1.5.5 shipped no rate limit, lockout, delay, or failure counter for authentication attempts (CWE-307). Real-world exploitability is bounded by password strength - the independent assessment rates the vector AC:H for exactly this reason - and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor added an in-process sliding-window limiter in 1.5.5.
Authentication bypass in HKUDS LightRAG before 1.5.4 lets a remote unauthenticated attacker defeat X-API-Key protection when the server runs in the API-key-only profile (LIGHTRAG_API_KEY set, AUTH_ACCOUNTS unset). Because auth.py falls back to a public hardcoded DEFAULT_TOKEN_SECRET and /auth-status and /login freely mint guest JWTs, combined_dependency honored a guest token before ever checking the API key, exposing document read/upload/delete, graph mutation, and query endpoints. No public exploit is identified at time of analysis, but the underlying fix (PR #3319) ships a regression test showing that forging a valid guest token with the default secret is trivial; fixed in 1.5.4.
Cross-origin data theft in LightRAG server versions prior to 1.5.4 allows any malicious website to make authenticated, credentialed API calls on behalf of a logged-in victim because the server ships with CORS_ORIGINS=* paired with allow_credentials=True. When an authenticated LightRAG user browses to an attacker-controlled page, that page can silently read documents and knowledge-graph data or issue destructive requests such as deleting the entire document store. No public exploit has been identified at time of analysis and the flaw is not in CISA KEV, but the fix is confirmed released in version 1.5.4.
Stored cross-site scripting (CWE-79) in the LightRAG WebUI prior to 1.5.5 lets an attacker who can ingest a document persist raw HTML that the query path later returns and renders as active content, executing JavaScript in the WebUI origin for any user who views the poisoned answer. The vulnerable sinks are ChatMessage.tsx, which renders answer and thinking content through react-markdown with rehypeRaw and skipHtml=false but no HTML sanitizer, and a Mermaid rendering path configured with securityLevel 'loose' that injects generated SVG via innerHTML; an attacker-supplied iframe srcdoc or crafted mermaid block is sufficient to run script. Successful exploitation lets the attacker read the API token held in the victim's localStorage and perform API actions as that user, so the assessed scope is changed (S:C) with limited confidentiality and integrity impact. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N (6.1), meaning the attacker requires authenticated ingestion capability and the victim must run a query that surfaces the content and view it in the WebUI; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Password recovery via a timing oracle in LightRAG's /login endpoint lets remote, unauthenticated attackers (CVSS PR:N/UI:N) reconstruct plaintext AUTH_ACCOUNTS passwords one character at a time by measuring microsecond-scale response-time differences in Python's short-circuiting '==' comparison, but only in deployments that store credentials as plaintext rather than bcrypt-prefixed values. The attack requires high attack complexity (AC:H) - low-latency network positioning, many samples to overcome jitter, and credentials short or simple enough to recover before noise or rate limiting defeats the oracle. It is fixed in v1.5.5, which also introduces uniform bcrypt timing and login rate limiting; no public exploit code was identified at time of analysis.
LightRAG API server versions prior to 1.5.5 return raw Python exception text to network clients through error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py, leaking server filesystem paths, database host/port/user/name, LLM provider diagnostics, and library internals. Exploitation is unauthenticated (CVSS PR:N) because the server ships with an open default configuration, and it requires only that the API be network-reachable plus a request that triggers a server-side exception; deployments using URI-configured backends whose drivers embed connection strings can also leak credentials. Scored CVSS 3.1 5.3 MEDIUM with confidentiality-only impact, and no public exploit code was identified at time of analysis.
Server-side request forgery (CWE-918) in LightRAG before 1.5.5 lets an authenticated caller who can upload a Markdown or textpack document point an external image URL at an IPv6 transition-wrapper literal (NAT64 well-known prefix 64:ff9b::/96 or an IPv4-compatible ::a.b.c.d form) that embeds a loopback, RFC1918, CGNAT, or cloud-metadata IPv4 address, causing the parser's image download to fetch the internal resource and ingest its body. The guard in lightrag/parser/markdown/parser.py evaluated only the literal address with ipaddress.is_global, which classifies these wrappers as globally routable, so the embedded internal target was never checked. Exploitation is conditional (AC:H): the deployment must have compatible NAT64/DNS64 routing for the wrapper to be delivered to the embedded target, which is why the assessed vector is AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). The issue is fixed in v1.5.5.
Unthrottled password guessing against the LightRAG POST /login endpoint allows an unauthenticated remote attacker to submit credential attempts at full request speed until a valid account password is recovered, after which the attacker gains authenticated access to documents, the knowledge graph, and administrative operations. Versions prior to 1.5.5 shipped no rate limit, lockout, delay, or failure counter for authentication attempts (CWE-307). Real-world exploitability is bounded by password strength - the independent assessment rates the vector AC:H for exactly this reason - and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor added an in-process sliding-window limiter in 1.5.5.
Authentication bypass in HKUDS LightRAG before 1.5.4 lets a remote unauthenticated attacker defeat X-API-Key protection when the server runs in the API-key-only profile (LIGHTRAG_API_KEY set, AUTH_ACCOUNTS unset). Because auth.py falls back to a public hardcoded DEFAULT_TOKEN_SECRET and /auth-status and /login freely mint guest JWTs, combined_dependency honored a guest token before ever checking the API key, exposing document read/upload/delete, graph mutation, and query endpoints. No public exploit is identified at time of analysis, but the underlying fix (PR #3319) ships a regression test showing that forging a valid guest token with the default secret is trivial; fixed in 1.5.4.
Cross-origin data theft in LightRAG server versions prior to 1.5.4 allows any malicious website to make authenticated, credentialed API calls on behalf of a logged-in victim because the server ships with CORS_ORIGINS=* paired with allow_credentials=True. When an authenticated LightRAG user browses to an attacker-controlled page, that page can silently read documents and knowledge-graph data or issue destructive requests such as deleting the entire document store. No public exploit has been identified at time of analysis and the flaw is not in CISA KEV, but the fix is confirmed released in version 1.5.4.
Stored cross-site scripting (CWE-79) in the LightRAG WebUI prior to 1.5.5 lets an attacker who can ingest a document persist raw HTML that the query path later returns and renders as active content, executing JavaScript in the WebUI origin for any user who views the poisoned answer. The vulnerable sinks are ChatMessage.tsx, which renders answer and thinking content through react-markdown with rehypeRaw and skipHtml=false but no HTML sanitizer, and a Mermaid rendering path configured with securityLevel 'loose' that injects generated SVG via innerHTML; an attacker-supplied iframe srcdoc or crafted mermaid block is sufficient to run script. Successful exploitation lets the attacker read the API token held in the victim's localStorage and perform API actions as that user, so the assessed scope is changed (S:C) with limited confidentiality and integrity impact. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N (6.1), meaning the attacker requires authenticated ingestion capability and the victim must run a query that surfaces the content and view it in the WebUI; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Password recovery via a timing oracle in LightRAG's /login endpoint lets remote, unauthenticated attackers (CVSS PR:N/UI:N) reconstruct plaintext AUTH_ACCOUNTS passwords one character at a time by measuring microsecond-scale response-time differences in Python's short-circuiting '==' comparison, but only in deployments that store credentials as plaintext rather than bcrypt-prefixed values. The attack requires high attack complexity (AC:H) - low-latency network positioning, many samples to overcome jitter, and credentials short or simple enough to recover before noise or rate limiting defeats the oracle. It is fixed in v1.5.5, which also introduces uniform bcrypt timing and login rate limiting; no public exploit code was identified at time of analysis.
LightRAG API server versions prior to 1.5.5 return raw Python exception text to network clients through error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py, leaking server filesystem paths, database host/port/user/name, LLM provider diagnostics, and library internals. Exploitation is unauthenticated (CVSS PR:N) because the server ships with an open default configuration, and it requires only that the API be network-reachable plus a request that triggers a server-side exception; deployments using URI-configured backends whose drivers embed connection strings can also leak credentials. Scored CVSS 3.1 5.3 MEDIUM with confidentiality-only impact, and no public exploit code was identified at time of analysis.