Summary
Open WebUI contains a server-side request forgery vulnerability in URL-based content retrieval when IPv4 destinations are represented through IPv6 transition encodings. On deployments using a NAT64 gateway, a verified user may cause the server to fetch internal services or cloud metadata endpoints and return their response content.
Affected context
The issue affects Open WebUI deployments from 0.9.0 through 0.11.0 when server-side URL retrieval features are enabled and outbound requests traverse a NAT64 gateway. Relevant functionality may include RAG URL ingestion, URL-to-markdown conversion, and web-search content retrieval. The risk exists where URL validation evaluates the literal IPv6 representation without resolving or inspecting an embedded IPv4 destination.
Exploit preconditions
- Attack surface: Server-side URL fetching used by RAG, markdown conversion, or web-search retrieval
- Required access: A verified Open WebUI user who can submit or cause a URL to be processed
- Network condition: The deployment uses a NAT64 gateway or comparable IPv6-to-IPv4 transition mechanism
- Trigger point: URL validation followed by an outbound fetch
- Why exploitation is possible: The validator may treat the transition-encoded IPv6 address as globally routable while the gateway delivers the request to an internal or metadata IPv4 address
Why this happens
The vulnerability results from incomplete SSRF validation. The application checks ipaddress.is_global against the literal IPv6 address but does not examine the IPv4 address represented through a transition encoding. Consequently, an address that appears globally routable at the validation layer may resolve through NAT64 to a private network or cloud metadata destination. This behavior maps to CWE-918: Server-Side Request Forgery, where attacker-influenced URLs are used for server-side network requests without complete destination restrictions.
Potential impact
- Internal service response bodies may be disclosed to an authorized user
- Cloud instance metadata or temporary credentials could be exposed
- Internal network topology and service details may be revealed
- The server may be used to reach administrative or otherwise restricted endpoints
- Retrieved sensitive content could be incorporated into RAG or search results
General mitigation guidance
Mitigation typically focuses on validating the effective destination of every server-side request rather than trusting its textual representation.
Common defensive patterns include:
- Resolve and normalize IPv4, IPv6, and transition-encoded addresses before policy evaluation
- Deny private, loopback, link-local, reserved, multicast, and cloud-metadata destinations after resolution
- Apply explicit outbound allowlists where URL retrieval is required
- Revalidate destinations across redirects and prevent DNS rebinding
- Restrict egress from application workers and isolate them from management and metadata networks
- Use a dedicated fetch service with minimal network privileges and bounded response handling
How teams detect issues like this
Organizations commonly detect SSRF risks through:
- Static analysis and code review checks for user-controlled URLs passed to HTTP clients
- Tests covering IPv4, IPv6, mapped and transition-encoded addresses, redirects, and DNS resolution changes
- Monitoring outbound requests from Open WebUI workers to private ranges, metadata endpoints, and unexpected internal services
- Network policy alerts for access to link-local metadata addresses or non-approved internal networks
- Policy enforcement requiring centralized URL validation and outbound allowlists
Automated application security and code review tools may help identify incomplete IP normalization and unrestricted server-side fetch paths.
