Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The LightRAG WebUI renders assistant/answer chat content as raw HTML — react-markdown is configured with rehypePlugins={[rehypeRaw]} and skipHtml={false} and no HTML sanitizer (rehype-sanitize), element allow-list, or custom urlTransform. Because answer content is derived from user-ingested documents, an attacker who can add a single document can store an HTML/JavaScript payload that executes in the browser of any user who later retrieves it (typically an administrator), leading to auth-token theft from localStorage and full API takeover. No authentication is required in the default configuration. Details Sink — lightragwebui/src/components/retrieval/ChatMessage.tsx: - Main answer (MessageMarkdown, lines ~348-351) and thinking content (lines ~252-272) render with rehypePlugins={[rehypeRaw, …]} and skipHtml={false}. The components map (lines ~111-156) only restyles safe formatting tags (p, h1–h4, ul, ol, li, code); there is no rehype-sanitize, no…
Recommended action: Upgrade to 1.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, validatedaddresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not isglobal. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python's ipaddress classifies a NAT64 (64:ff9b::/96 and the RFC 8215 64:ff9b:1::/48 prefix), IPv4-compatible (::a.b.c.d), or 6to4 (2002::/16) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (::ffff:) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter. Affected component and versions -…
Recommended action: Upgrade to 1.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The POST /login endpoint has no rate limiting, account lockout, or delay on failed attempts. An attacker can submit unlimited password guesses at full network speed. Details A search for slowapi, ratelimit, lockout, or throttle in lightrag/api/ returns zero results. PoC Impact Improper restriction of authentication attempts. Any network-reachable attacker can brute-force user passwords without restriction. Once credentials are recovered, the attacker gains full authenticated access to all documents, knowledge graph, and administrative operations.
Recommended action: Upgrade to 1.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When plaintext passwords are stored in AUTHACCOUNTS, the comparison uses Python's == operator which is not constant-time. An attacker with low-latency access can exploit timing differences to recover the password character by character. Details PoC Impact Observable timing discrepancy. Attackers with low-latency access can recover plaintext passwords character by character without triggering brute-force limits. Only affects deployments using unhashed passwords in AUTHACCOUNTS.
Recommended action: Upgrade to 1.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LightRAG API server passes raw Python exception messages directly into HTTP error responses across 30+ error handlers in every router. When combined with the default unauthenticated configuration (see companion report on CWE-306), any network-reachable client can trigger exceptions whose raw text discloses internal infrastructure — server filesystem paths, database host/port/user, LLM provider error details, and Python library internals. No global exception handler sanitizes error messages before they reach the client. Details Throughout the API route handlers, exceptions are caught and their string representation is returned verbatim via detail=str(e) / detail=str(exc) (and f-string variants such as detail=f"...: {str(e)}"). This occurs in every router file. Location breakdown on the current main branch: HTTP 500 — raw exception passthrough (except Exception as e): - documentroutes.py — 13 - graphroutes.py — 12 (mix of detail=f"...{str(e)}" and detail=errormsg) -…
Recommended action: Upgrade to 1.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When LightRAG is deployed with LIGHTRAGAPIKEY set but AUTHACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULTTOKENSECRET committed in the repository and then call any endpoint guarded by Depends(combinedauth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clearcache, and POST /query. This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTHACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15). Root cause Three independent issues combine: 1. lightrag/api/config.py:54 ships a hardcoded default JWT secret: 2. lightrag/api/auth.py:28-38 falls back to…
Recommended action: Upgrade to 1.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The server defaults to CORSORIGINS= combined with allowcredentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user. Details PoC Host on any origin. Open in browser where user is logged in to LightRAG: Impact Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.
Recommended action: Upgrade to 1.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access. Details In lightrag/api/auth.py at line 128, the validatetoken method calls: This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication. PoC An attacker can generate a JWT with the following structure: Then send a request like: Impact An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials. Recommended Fix Explicitly specify allowed algorithms and exclude 'none'. Modify the validatetoken…
Recommended action: Upgrade to 1.4.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Subject: Security Vulnerability Report Hardcoded JWT Secret (CVE-2026-30762) Hi HKUDS team, I'm writing to report a security vulnerability I discovered in LightRAG v1.4.10. This has been assigned CVE-2026-30762 by MITRE. Vulnerability: Hardcoded JWT signing secret Type: Improper Authentication (CWE-287) Severity: High Attack Vector: Remote / Unauthenticated Summary: The file lightrag/api/config.py (line 397) uses a default JWT secret "lightrag-jwt-default-secret" when the TOKENSECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint. Reproduction: 1. Install LightRAG v1.4.10 with AUTHACCOUNTS configured but no TOKENSECRET set 2. Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256") 3. Send a request to…
Recommended action: Upgrade to 1.4.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in HKUDS LightRAG up to 1.3.8. It has been declared as critical. Affected by this vulnerability is the function uploadtoinputdir of the file lightrag/api/routers/documentroutes.py of the component File Upload. The manipulation of the argument file.filename leads to path traversal. It is possible to launch the attack on the local host. The identifier of the patch is 60777d535b719631680bcf5d0969bdef79ca4eaf. It is recommended to apply a patch to fix this issue.
Recommended action: Upgrade to 1.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.