Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-54020

CVE-2026-54020: Open WebUI SSRF Vulnerability

CVE-2026-54020 is an SSRF flaw in Open WebUI allowing attackers to exploit DNS rebinding to access internal services and cloud metadata. This article covers technical details, affected versions, and mitigation steps.

Published:

CVE-2026-54020 Overview

CVE-2026-54020 is a Server-Side Request Forgery (SSRF) vulnerability in Open WebUI, a self-hosted AI platform. The flaw affects all versions prior to 0.11.0 and stems from a Time-of-Check Time-of-Use (TOCTOU) race condition [CWE-367] in hostname validation. Authenticated attackers who control authoritative DNS for a submitted hostname can bypass private address filtering. The URL validator resolves the hostname to a public address, but the HTTP client re-resolves it to an internal address at connection time. This DNS rebinding technique allows attackers to reach cloud metadata endpoints, loopback administrative APIs, and internal services.

Critical Impact

Attackers can exfiltrate cloud metadata credentials and OAuth access tokens by pivoting requests to internal services through URL ingest, chat image fetches, image editing, and OAuth profile-picture retrieval paths.

Affected Products

  • Open WebUI versions prior to 0.11.0
  • Self-hosted Open WebUI deployments with URL ingest, image, or OAuth integrations enabled
  • Cloud-hosted Open WebUI instances with access to instance metadata services (IMDS)

Discovery Timeline

  • 2026-08-04 - CVE-2026-54020 published to NVD
  • 2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-54020

Vulnerability Analysis

Open WebUI performs URL validation by resolving the submitted hostname and rejecting private, loopback, and link-local addresses. However, the underlying HTTP clients perform their own DNS resolution when establishing the connection. This produces two independent DNS lookups for a single request. An authenticated attacker controlling the authoritative DNS server for the submitted hostname can return different answers to each lookup. The validation lookup receives a public IP address and passes the allowlist checks. The connection-time lookup receives an internal address such as 169.254.169.254, 127.0.0.1, or an RFC1918 host.

Affected code paths include URL ingest, chat image_url fetches, image editing operations, and OAuth profile-picture retrieval. Most paths return the fetched response body to the attacker. The OAuth path is more severe because it forwards the OAuth access token to the attacker-controlled destination.

Root Cause

The root cause is a classic TOCTOU race between hostname validation and hostname use [CWE-367]. Validation logic and HTTP client logic do not share a single resolved address. Instead, each independently invokes the system resolver, creating a window for DNS rebinding.

Attack Vector

An authenticated attacker registers a domain and points it at a DNS server they control. The attacker submits a URL referencing that domain to an affected endpoint such as URL ingest or OAuth profile-picture fetch. The DNS server answers the validation query with a public address and answers the connection query with an internal address such as the cloud metadata IP or a loopback admin API. The server connects to the internal target and returns the response, or in the OAuth flow forwards the access token, to the attacker.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-h6x2-583h-x99r for the vendor description.

Detection Methods for CVE-2026-54020

Indicators of Compromise

  • Outbound HTTP requests from the Open WebUI process to 169.254.169.254, 127.0.0.1, or RFC1918 ranges shortly after inbound URL ingest, image, or OAuth callbacks.
  • DNS query logs showing multiple resolutions of the same hostname within seconds returning different address families (public then private).
  • Access logs showing authenticated users submitting URLs whose authoritative DNS TTL is set to zero or near-zero.

Detection Strategies

  • Correlate application-level URL submission events with egress netflow to identify requests reaching internal or metadata addresses.
  • Instrument the resolver to log all lookups issued by the Open WebUI process and alert on repeated lookups for identical hostnames returning divergent answers.
  • Monitor OAuth flows for profile-picture fetches that terminate at non-provider IP addresses.

Monitoring Recommendations

  • Enable cloud provider IMDSv2 and alert on any IMDS access originating from the Open WebUI workload.
  • Log all outbound HTTP requests made by URL ingest, image, and OAuth handlers with resolved destination IP recorded at connection time.
  • Alert on any Open WebUI egress traffic to loopback, link-local, or private address space.

How to Mitigate CVE-2026-54020

Immediate Actions Required

  • Upgrade Open WebUI to version 0.11.0 or later, which resolves the TOCTOU condition.
  • Restrict egress from the Open WebUI host to only the AI providers and object stores it must reach.
  • Enforce IMDSv2 with hop limit 1 on cloud instances hosting Open WebUI to block SSRF-to-metadata pivots.
  • Review OAuth application logs for suspicious profile-picture fetch destinations since deployment.

Patch Information

The fix is available in Open WebUI Release v0.11.0. The patch ensures that the address validated is the same address used for connection, eliminating the DNS rebinding window. Full details are in the GitHub Security Advisory GHSA-h6x2-583h-x99r.

Workarounds

  • Place Open WebUI behind an egress proxy that enforces destination allowlisting on resolved IP addresses rather than hostnames.
  • Block outbound access from Open WebUI to 169.254.169.254/32, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 at the network layer.
  • Disable OAuth profile-picture fetching and external URL ingest features until the upgrade is applied.
bash
# Example iptables rules blocking SSRF pivot targets from the Open WebUI host
iptables -A OUTPUT -d 169.254.169.254/32 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.