LightRAG EUVD-2026-84549

Two prerequisites must both hold. First, the attacker must be an authenticated caller who can upload a Markdown or textpack document to LightRAG (PR:L). Second - and this is the decisive limiter - the deployment must have compatible NAT64 or DNS64 routing configured, so that the IPv6 transition-wrapper literal (NAT64 well-known prefix 64:ff9b::/96 or an IPv4-compatible ::a.b.c.d form) is actually delivered to the embedded internal IPv4. Without NAT64/DNS64 the wrapped literal does not route to the intended internal target and the SSRF fails, which is why the vendor rated AC:H. The embedded IPv4 must point at a non-public target (loopback, RFC1918, link-local cloud-metadata 169.254.169.254, or CGNAT). Note IPv4-mapped ::ffff: forms and 6to4/RFC 8215 local-use NAT64 were already blocked pre-fix; the exploitable gap was specifically the NAT64 well-known /96 and IPv4-compatible wrappers whose literal classified as globally routable. Operators who deliberately run local NAT64 can also widen exposure via the NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS escape hatch.

This is a genuine but conditional SSRF (CWE-918), not a drop-everything issue. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N = 7.1) is internally consistent with the description and I concur with it: network-reachable, but AC:H correctly reflects that exploitation only works 'on a deployment with compatible NAT64 or DNS64 routing' - a non-default network precondition - and PR:L reflects that the attacker must be an authenticated caller able to upload a Markdown/textpack document. No EPSS score, no CISA KEV listing, and no public POC are provided; per precision rules this is 'no public exploit identified at time of analysis.' The absence of exploitation signals combined with AC:H and the specialized NAT64/DNS64 routing requirement means real-world exploitability is narrow rather than mass-scannable, despite the HIGH-band 7.1 CVSS. The confidentiality impact (C:H) is credible because the classic SSRF target here is cloud instance-metadata (169.254.169.254) yielding credentials, and the fetched internal-resource body is ingested into the RAG store - so a data-exfiltration path is real where the routing precondition holds. No conflicting signals in the vector; the main caveat is the environmental dependency (NAT64/DNS64) that CVSS base metrics cannot express and AC:H only partially captures.

An authenticated user of a self-hosted LightRAG instance that sits behind NAT64/DNS64 routing uploads a Markdown or textpack document containing an external image URL written as an IPv6 transition wrapper (e.g. NAT64 well-known prefix 64:ff9b::a9fe:a9fe or an IPv4-compatible ::a9fe:a9fe encoding 169.254.169.254). The literal address passes the old is_global check, so the server fetches the wrapped internal target - cloud metadata, loopback, or an RFC1918 service - and ingests the response body, leaking internal data or cloud credentials. No public exploit code is identified, but the technique is well-documented and the fix explicitly enumerates the bypassing wrappers.