CVE-2026-85740 in LightRAG
Summary
by MITRE • 09/22/2026
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in LightRAG versions prior to 1.5.5 represents a critical server-side request forgery flaw rooted in improper validation of network addresses within document parsing logic. The core technical defect lies in the _validated_addresses function located in the lightrag/parser/markdown/parser.py module, which relies on Python’s standard library ipaddress.is_global method to determine address validity. This approach fails to account for IPv4-mapped or IPv4-compatible addresses embedded within IPv6 transition wrappers, such as those defined by NAT64 using the 64:ff9b::/96 prefix or legacy IPv4-compatible forms. Consequently, an attacker can craft a Markdown or textpack document containing an external image URL that appears to be a public global address but actually resolves to an internal private IP range, loopback interface, or cloud metadata endpoint when processed through NAT64 or DNS64 routing mechanisms present in the deployment environment.
From an operational perspective, this flaw allows for significant information disclosure and potential remote code execution depending on the surrounding application context. By uploading a maliciously constructed document with an image source pointing to an internal resource disguised as a global IPv6 address, an attacker can force the LightRAG server to fetch and ingest sensitive data from internal services that are not intended to be accessible externally. This includes cloud metadata endpoints which often contain authentication tokens or configuration secrets, private database interfaces, or local administrative panels. The _download and _build_guarded_opener functions accept these wrapped addresses without sufficient scrutiny of the underlying IPv4 payload, leading to the ingestion of unauthorized internal resources into the retrieval-augmented generation pipeline. This behavior violates the principle of least privilege by allowing external inputs to trigger interactions with protected internal network segments.
This vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically where the application fails to validate that a user-supplied URL resolves to an expected public address space before making server-side requests. It also relates to CWE-20 Improper Input Validation, as the input sanitization logic does not correctly handle edge cases involving IPv6 transition mechanisms and their interaction with IPv4 addressing schemes. In terms of offensive security frameworks, this exploit maps to ATT&CK technique T1598 Phishing for Information, where an attacker uses social engineering or document upload capabilities to trick a system into accessing internal resources that can be exfiltrated through the application’s output channels or side effects during ingestion.
The resolution involves updating LightRAG to version 1.5.5 and later, which implements a more robust guard mechanism for address validation. This fix ensures that all documented IPv6 transition wrappers are correctly evaluated against their underlying IPv4 components, preventing the bypass of global address checks via NAT64 or similar translation techniques. The updated logic maintains strict adherence to standard library behaviors while closing the loophole that allowed internal addresses to be masqueraded as public ones. Organizations running LightRAG must apply this patch immediately and audit any existing documents for potential malicious payloads if they have been exposed in an unpatched environment. Additionally, defense-in-depth measures such as network segmentation, egress filtering, and disabling cloud metadata access from application servers should be employed to mitigate the impact of similar SSRF vulnerabilities in other components.