CVE-2026-70485: Server-Side Request Forgery in Open WebUI via NAT64 IP Wrapping Bypass

Open WebUI is an extensible, self-hosted AI platform containing features for Retrieval-Augmented Generation (RAG) ingestion, web-search retrieval, and URL-to-markdown conversion. To facilitate these features, the application accepts user-supplied URLs and fetches their content. To prevent Server-Side Request Forgery (SSRF) attacks against internal endpoints, the application implements an IP address validation mechanism.

From version 0.9.0 up to version 0.11.0, this validation mechanism relies on verifying whether the resolved IP addresses of the destination host are globally routable. However, the validation layer is insufficient when deployed within environments utilizing transition mechanisms, such as NAT64 gateways. This insufficient validation allows authenticated remote users to bypass SSRF controls and access local or cloud-metadata endpoints.

The root cause of the vulnerability lies in the implementation of the IP validation logic in backend/open_webui/retrieval/web/utils.py. The system attempts to resolve user-supplied hostnames and passes the resulting IP addresses to the standard Python ipaddress library to check the is_global property. If the property evaluates to false, the request is blocked as a local or private address.

In dual-stack or IPv6-only network environments, a NAT64 gateway is commonly employed to translate IPv4 traffic to IPv6. This translation is typically accomplished by prepending a Well-Known Prefix (WKP) of 64:ff9b::/96 (RFC 6052) or a Network-Specific Prefix (NSP) to the target IPv4 address. For example, the AWS metadata address 169.254.169.254 becomes [64:ff9b::a9fe:a9fe] under the standard NAT64 prefix.

Python's standard library ipaddress module treats the 64:ff9b::/96 block as part of the globally routable IPv6 address space. Consequently, checking ipaddress.ip_address("64:ff9b::a9fe:a9fe").is_global returns True. This allows transition-wrapped private IPv4 addresses to bypass the validation filters and reach the NAT64 gateway, which decapsulates the address back to its private IPv4 form and completes the connection.

In vulnerable versions, the application validated the IP address directly using ipaddress.ip_address(ip).is_global without inspecting for transition encodings. The patch introduced in commit 1717b493d83c86afa82aa8bc50139250852dd2f3 implements a helper function _is_global_addr(ip) to recursively unwrap embedded IPv4 addresses from transition protocols.

# File: backend/open_webui/retrieval/web/utils.py
 
def _is_global_addr(ip: str) -> bool:
    addr = ipaddress.ip_address(ip)
    if not addr.is_global:
        return False
    if not isinstance(addr, ipaddress.IPv6Address):
        return True
 
    embedded = []
    if addr.ipv4_mapped:
        embedded.append(addr.ipv4_mapped)
    if addr.sixtofour:
        embedded.append(addr.sixtofour)
    if addr.teredo:
        embedded.extend(addr.teredo)
 
    b = addr.packed
    if b[:12] == b"\x00" * 12:
        embedded.append(ipaddress.IPv4Address(b[12:]))
    elif b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        embedded.append(ipaddress.IPv4Address(b[12:]))
    elif b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        if b[8] != 0:
            return False
        embedded.append(ipaddress.IPv4Address(bytes((b[6], b[7], b[9], b[10]))))
 
    return all(ip.is_global for ip in embedded)

The helper parses standard transition mechanisms including IPv4-mapped, 6to4, and Teredo addresses. It also implements manual byte-level matching for the NAT64 Well-Known Prefix (64:ff9b::/96) and the local-translation prefix (64:ff9b:1::/48) to extract the nested IPv4 address. The function then evaluates whether all extracted nested addresses are globally routable.

An attacker must have authenticated access to the Open WebUI instance. The exploitation relies on entering a specially crafted URL into features like the RAG URL ingestion or web-search field. The attacker translates the target private IPv4 address, such as the link-local metadata address 169.254.169.254, into its hexadecimal representation a9fe:a9fe and prepends the NAT64 prefix.

The resulting URL http://[64:ff9b::a9fe:a9fe]/latest/meta-data/ is submitted to the application. The backend validates the host by resolving the hostname and passing the IPv6 address to ipaddress.is_global. Because the Python library considers this address global, the validation checks pass.

The HTTP request is then dispatched. The outbound packet reaches the NAT64 gateway, which strips the prefix and forwards the TCP connection to the cloud metadata service on 169.254.169.254. The metadata service responds with the requested credentials, which are returned to the application and displayed to the user.

Successful exploitation of this SSRF vulnerability permits an authenticated attacker to read sensitive data from internal systems. This is particularly critical in cloud-native environments where the metadata endpoints (such as AWS EC2 metadata, Google Cloud metadata, or Kubernetes APIs) contain active IAM credentials, configuration parameters, and access tokens.

The vulnerability is classified with a CVSS 3.1 score of 7.1 (High) and vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N. The complexity is rated high because the attack succeeds only on environments with dual-stack transitions or active NAT64 configurations. If these conditions are met, the confidentiality impact is high.

While there is currently no evidence of active exploitation in the wild, the maturity of the vulnerability remains theoretical. The exposure is limited to deployments using NAT64 translation services, which are common in IPv6-only container networks.

The vulnerability is remediated in version 0.11.0 of Open WebUI. Administrators must upgrade their instances to this version or later to apply the validation helper. If an immediate upgrade is not feasible, administrators can disable local web-fetching functionality entirely by configuring the environment variable ENABLE_LOCAL_WEB_FETCH=False.

Additionally, host-level firewall configurations or security groups should be configured to drop outgoing traffic from the Open WebUI container to sensitive private addresses. For example, blocking access to 169.254.169.254/32 at the network level prevents successful exploitation regardless of application-level bypasses.

While the patch effectively blocks transitions using standard prefixes, it does not explicitly handle custom Network-Specific Prefixes (NSPs) defined by local network administrators. If a custom NSP is utilized for the NAT64 gateway, an attacker who obtains the prefix can construct a bypass. Therefore, network-level segregation remains the recommended defense-in-depth practice.