SSRF Vulnerability in Open WebUI via NAT64-encoded URLs
Authenticated users can bypass SSRF protection in Open WebUI by wrapping internal IPv4 addresses in NAT64 IPv6 transition prefixes, allowing unauthorized access to cloud metadata and internal network services.
What's new
- 1. added coverage for Open WebUI (0.9.0 to 0.10.2) Aug 5, 02:01 via ghsa
- 2. added coverage for Open WebUI (0.10.0-0.10.2) Aug 5, 02:01 via ghsa
- 3. added detection rule: Detect CVE-2026-70494 - Unauthorized Folder Deletion Attempts Aug 5, 02:01 via ghsa
- 4. added coverage for Open WebUI (0.9.6 to 0.10.x) Aug 4, 20:01 via ghsa
- 5. poc_available; added CVE-2026-70482; open webui version < 0.11.0 Aug 4, 20:00 via ghsa
Open WebUI (v0.9.0 through v0.10.x) contains an SSRF vulnerability (CVE-2026-70485) stemming from insecure URL validation logic. When processing user-supplied URLs for RAG or web-search features, the application performs connectivity checks to ensure the destination is globally routable. However, this validation uses the ipaddress.ip_address(ip).is_global check on the literal IPv6 address, failing to account for embedded IPv4 addresses within NAT64 transition prefixes (specifically 64:ff9b::/96).
On cloud environments or Kubernetes clusters configured with NAT64 gateways, an attacker can mask internal IPv4 addresses (such as 169.254.169.254 or 127.0.0.1) using these prefixes. Because the literal IPv6 representation is technically globally routable, the filter is bypassed. The server subsequently fetches the internal content and returns the raw response body to the attacker via the API. This vulnerability allows low-privilege users to exfiltrate sensitive data, including IAM credentials from cloud instance metadata services or interface with admin endpoints bound to localhost.
Attack Chain
- Attacker authenticates to an Open WebUI instance as a standard user.
- Attacker selects a feature utilizing URL ingestion or web retrieval (e.g.,
/api/v1/retrieval/process/web). - Attacker identifies a target internal resource (e.g., Cloud Metadata service at 169.254.169.254).
- Attacker encodes the target IPv4 address into the NAT64 well-known prefix (
64:ff9b::/96) to create a literal IPv6 string. - Attacker submits the crafted URL (e.g.,
http://[64:ff9b::a9fe:a9fe]/latest/meta-data/) to the vulnerable API endpoint. - The application's
validate_url()and_ssrf_safe_new_conn()logic incorrectly flag the NAT64-encoded literal as a valid global IPv6 address. - The backend performs an HTTP GET request to the internal destination via the NAT64 gateway.
- The sensitive response body is returned to the attacker in the
contentfield of the API response.
Impact
Successful exploitation leads to unauthorized read access to internal network services, private APIs, and cloud instance metadata. Attackers can retrieve IAM role credentials, allowing for potential lateral movement from the container to the broader cloud environment. The impact is restricted to deployments utilizing NAT64 gateways, which are standard in modern IPv6-only or dual-stack cloud/Kubernetes network architectures.
Recommendation
- Upgrade Open WebUI to version 0.11.0 or later to apply the patch for CVE-2026-70485, which correctly unwraps embedded IPv4 addresses before validation.
- Implement network-level egress filtering (Security Groups or Network Policies) to restrict the Open WebUI container from reaching internal cloud metadata IPs (e.g., 169.254.169.254) and private IP ranges.
- Monitor logs for requests to web-retrieval endpoints that contain literal IPv6 addresses starting with
64:ff9b.
Immediate actions
Upgrade Open WebUI to v0.11.0
Mitigations
Restrict container egress to cloud metadata and RFC1918 ranges
CVE-2026-70485
Detection coverage 2
Detect Potential SSRF Exploitation via NAT64 Encodings
highDetects web-retrieval API requests containing NAT64-encoded IPv6 literals, which may indicate an attempt to bypass SSRF filters (CVE-2026-70485).
Detect CVE-2026-70494 - Unauthorized Folder Deletion Attempts
mediumDetects DELETE requests to the folders API which may indicate exploitation attempts by collaborators against shared folders
Detection queries are available on the platform. Get full rules →