CVE-2026-85740: Server-Side Request Forgery (SSRF) Guard Bypass via IPv6 Transition Wrappers in LightRAG

The HKUDS/LightRAG framework is designed to provide fast and simple retrieval-augmented generation (RAG) processes. To support markdown ingestion, the framework parses uploaded files and retrieves external assets, such as images, to integrate them into the knowledge base. This operation exposes a significant attack surface if input URLs are not strictly validated before network resolution.

To defend against Server-Side Request Forgery (SSRF), the framework employs an IP-level validation mechanism. It resolves the hostnames specified in the image tags and validates the resulting IP addresses. This validation relies on checking whether the destination address is globally routable.

A critical security flaw exists in the validation logic within lightrag/parser/markdown/parser.py. The validation routine fails to detect and normalize IPv6 transition wrappers that encapsulate internal or private IPv4 addresses. This allows authenticated users with document upload privileges to circumvent the safety boundary.

The root cause of the vulnerability lies in the reliance on the standard library's ipaddress package for identifying globally routable IP addresses. When validating a resolved IP, the parser inspects the ip.is_global attribute. The parser permits the request if this attribute evaluates to True or if the address matches an explicitly allowed network subnet.

IPv6 transition technologies, designed to facilitate communication between IPv4 and IPv6 networks, encapsulate 32-bit IPv4 addresses within a 128-bit IPv6 container. Common transition formats include NAT64 well-known prefixes (RFC 6052), IPv4-compatible addresses (RFC 4291), 6to4 tunneling (RFC 3056), and local-use NAT64 prefixes (RFC 8215). These formats represent internal IPv4 destinations, such as 127.0.0.1 or 169.254.169.254, using valid global IPv6 prefixes.

Python's interpreter processes these encapsulated literals as globally routable because the outer prefix block is classified as global. For instance, the library evaluates 64:ff9b::7f00:1 (which embeds the localhost address 127.0.0.1) as globally routable. When the application issues the outbound HTTP request, the hosting environment's dual-stack socket layer decapsulates the prefix and routes the packet to the internal IPv4 target.

In vulnerable versions of LightRAG, the parser checks destination validity by directly querying the is_global property of the resolved IP object. The relevant code path is located in the _validated_addresses() function within lightrag/parser/markdown/parser.py.

# Vulnerable validation logic
if not (ip.is_global or any(ip in net for net in allow)):
    return []

The patch introduces a normalization wrapper to extract the underlying IPv4 address from known IPv6 transition formats. It also establishes a strict default-deny policy for specific blocks.

# Remediation implementation
_FORCE_NON_GLOBAL_V6 = (ip_network("64:ff9b:1::/48"), ip_network("2002::/16"))
 
def _unwrap_embedded_ipv4(ip):
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    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:])
    return ip

This extraction process ensures that the RAG pipeline applies security checks to the actual destination address. By unwrapping these formats, the validation engine correctly recognizes local loops and private subnets hidden inside IPv6 structures.

An attack requires document upload privileges within the LightRAG instance. The attacker crafts a malicious markdown document containing image tags referencing wrapped IPv6 transition addresses. When the server processes this document, the image download module is triggered.

The target infrastructure must run a dual-stack configuration or be deployed within an IPv6-only cloud subnet that utilizes NAT64 or DNS64 resolution services. Standard deployments in environments like AWS or Google Cloud commonly incorporate these configurations. The attacker converts the target local or private IPv4 address to its hexadecimal equivalent to structure the payload.

# Document ingestion test
![exfiltrate](http://[64:ff9b::a9fe:a9fe]/latest/meta-data/iam/security-credentials/)

Upon ingestion, the resolved host is verified as safe by the RAG application. The outbound request is dispatched, and the platform network layer strips the prefix. The underlying host routes the request directly to the instance metadata service, returning sensitive IAM credentials or local services.

The security impact of CVE-2026-85740 is rated as High, with a CVSS base score of 7.1. This rating reflects the capacity of an attacker to breach logical trust boundaries. The attack allows access to internal systems that are otherwise shielded from public network interaction.

Successful exploitation enables arbitrary request routing to localhost loopbacks, internal development subnets, and cloud management interfaces. Attackers can leverage this access to perform service enumeration, exploit internal endpoints lacking authentication, or harvest cloud metadata credentials. Exposure of credentials from instance metadata services often leads to further cloud infrastructure compromise.

The vulnerability does not directly permit remote code execution on the host without downstream exploitation of target services. Integrity impact is constrained to the state of internal APIs that accept modification commands. The scope is changed because the execution environment can query external trust boundaries.

The primary remediation for CVE-2026-85740 is upgrading HKUDS/LightRAG to version 1.5.5 or higher. The fixed version incorporates target normalization of IPv6 transition wrappers before evaluating routability. It also enforces block-level denials for deprecated or ambiguous blocks.

If immediate package upgrades are unfeasible, organizations should implement host-level mitigations. For instance, disabling instance metadata service access or requiring IMDSv2 with a hop limit of one prevents credentials harvesting. Restricting outbound HTTP communication from the container to verified remote domains also reduces the risk.

Additionally, organizations can deploy an explicit outbound proxy. Forcing all outbound RAG connections through a secure forward proxy that strictly filters destinations ensures that any bypassed requests are blocked at the network perimeter.