CVE-2026-54008: Open WebUI SSRF via OAuth Redirect Validation Bypass

Technical summary

The vulnerability resides in backend/open_webui/utils/oauth.py within the _process_picture_url function. The function calls validate_url() only on the user-supplied picture_url parameter, then fetches it using aiohttp.ClientSession.get() with default redirect behavior enabled (allow_redirects=True, max_redirects=10). The application fails to pass its AIOHTTP_CLIENT_ALLOW_REDIRECTS environment configuration, leaving the function vulnerable to HTTP redirect attacks. An authenticated OAuth user can supply a URL pointing to a public server they control, which responds with a 302 redirect to an internal network address (e.g., 127.0.0.1, 192.168.x.x, or internal service endpoints). The aiohttp client transparently follows the redirect, retrieves content from the internal address, and the response body becomes accessible to the attacker via their stored profile_image_url field. This maps to CWE-918 (Server-Side Request Forgery).

Business impact

This vulnerability enables authenticated attackers to exfiltrate sensitive data from internal networks reachable from the Open WebUI host. In environments where Open WebUI is deployed alongside internal services—databases, configuration endpoints, cloud metadata services, or internal APIs—an attacker with any valid OAuth account can enumerate and read responses from those services. Even in air-gapped deployments, if the Open WebUI instance has network access to internal resources, those resources become readable to any OAuth user. The confidentiality impact is high; the ability to modify internal services is limited but possible depending on what internal endpoints expose. Organizations relying on OAuth as a trust boundary should consider it insufficient; Open WebUI authentication alone does not prevent this attack.

Affected systems

Open WebUI versions prior to 0.9.6 are affected. The vulnerable code path is activated whenever an authenticated OAuth user provides a profile picture URL during account setup or update. The vulnerability does not require special network configuration; it affects any Open WebUI deployment that accepts OAuth logins and allows profile picture URLs.

Exploitability

Exploitability is straightforward. An attacker needs a valid OAuth identity from an IdP trusted by the target Open WebUI instance (or from an IdP that the attacker controls if the OpenWebUI admin has added it). The attacker then supplies a crafted URL pointing to a public redirect service under their control. No user interaction is required beyond account creation/profile update. No special tools are needed; standard HTTP 302 redirects suffice. The barrier to exploitation is authentication, but in many scenarios OAuth is relatively easy to obtain (social login, open IdP, compromised third-party account, or internal IdP access). The CVSS score of 8.5 (HIGH) reflects this: network-accessible, low attack complexity, requires login (PR:L), but scope changes and confidentiality impact is high.

Remediation

Upgrade Open WebUI to version 0.9.6 or later. This release fixes the redirect handling in _process_picture_url by respecting the AIOHTTP_CLIENT_ALLOW_REDIRECTS configuration and/or disabling redirects during profile picture fetches. Organizations unable to upgrade immediately should restrict OAuth IdP access to trusted users only, disable profile picture functionality if possible, or place Open WebUI behind a network boundary that prevents outbound access to internal services.

Patch guidance

Apply the patch by upgrading to Open WebUI 0.9.6 or later. Verify the upgrade in your deployment logs or admin interface. No configuration changes are required; the fix is in the application code. If you maintain a fork or custom build, review the changes in open_webui/utils/oauth.py to ensure redirect handling is disabled or properly configured. Test that profile picture uploads still function after patching.

Detection guidance

Monitor Open WebUI's HTTP client logs (if available) for outbound requests to unusual or internal IP addresses triggered by profile picture operations. Inspect the aiohttp session configuration at runtime to confirm redirects are disabled. Review profile picture URLs stored in the database for any that point to redirect services or external hosts (legitimate profile pictures typically point directly to stable image URLs). Monitor internal services for unexpected requests originating from the Open WebUI process, particularly to metadata endpoints, database ports, or management interfaces. Enable verbose OAuth logging to correlate suspicious profile updates with specific user accounts.

Why prioritize this

This issue merits prompt attention because it enables attackers with valid OAuth credentials to read arbitrary internal network content. While it requires authentication, OAuth is often easier to obtain than direct application access, especially in organizations using social login or federated identity. The CVSS score of 8.5 reflects the high confidentiality impact and scope change. Organizations with internal services on the same network as Open WebUI should prioritize patching immediately. Even air-gapped or offline deployments that allow internal OAuth users are at risk.

Risk score, explained

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N yields 8.5 (HIGH). The vector reflects: network-accessible attack surface (AV:N), low attack complexity (AC:L), requirement for valid login credentials (PR:L), no user interaction needed (UI:N), scope change because the attacker can access systems beyond Open WebUI itself (S:C), high confidentiality impact (C:H), limited integrity impact (I:L) from potential internal service modification, and no availability impact (A:N). The scope change—enabling access to internal resources—elevates the score despite the authentication requirement.

Frequently asked questions