CVE-2026-45339: Open WebUI Auth Bypass Vulnerability

CVE-2026-45339 Overview

CVE-2026-45339 is an authorization bypass vulnerability in Open WebUI, a self-hosted artificial intelligence platform designed to operate entirely offline. The flaw affects all versions prior to 0.9.0 and stems from inconsistent enforcement of API key endpoint restrictions. Administrators can scope API keys to block access to specific endpoints such as /api/v1/messages, but the restriction only applies when the key is submitted through the Authorization: Bearer header. Sending the same key via the x-api-key header bypasses the restriction, allowing authenticated requests to invoke models and receive full responses. The vulnerability is classified under CWE-863: Incorrect Authorization.

Critical Impact
A restricted API key can invoke prohibited endpoints by switching authentication headers, defeating administrator-defined access controls and exposing model functionality to unauthorized callers.

Affected Products

Open WebUI versions prior to 0.9.0
Self-hosted Open WebUI deployments using API key restrictions
Open WebUI instances exposing /api/v1/messages endpoints

Discovery Timeline

2026-05-15 - CVE-2026-45339 published to NVD
2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-45339

Vulnerability Analysis

Open WebUI supports administrator-defined API key scoping that restricts which endpoints a given key may invoke. When a request arrives with the Authorization: Bearer sk-... header targeting a restricted endpoint such as /api/v1/messages, the server correctly rejects it with HTTP 403. The authorization middleware fails to apply the same restriction logic to the alternate x-api-key header. Requests authenticated through x-api-key reach the protected route handler, the model is invoked, and the full response is returned to the caller.

The issue is a textbook [CWE-863] incorrect authorization condition, where two code paths authenticate the same credential but only one enforces scope checks. The vulnerability requires an attacker to possess a valid API key, so exploitation depends on prior key exposure, insider access, or compromise of a low-privileged account that legitimately holds a restricted key.

Root Cause

The restriction enforcement logic is bound to the Authorization header parsing path. The x-api-key header is parsed by a separate authentication routine that resolves the key to a user identity without consulting the endpoint allow-list associated with that key. The two authentication entry points diverge before reaching the scope validator.

Attack Vector

An attacker holding a scoped API key crafts an HTTP request to a restricted endpoint and substitutes the x-api-key header for the Authorization: Bearer header. The server authenticates the key, skips the endpoint allow-list check, and processes the request. The attack is purely network-based, requires no user interaction, and produces no error visible to the administrator who scoped the key.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-57q6-fvp4-pqmm for vendor-provided details.

Detection Methods for CVE-2026-45339

Indicators of Compromise

Successful HTTP 200 responses on /api/v1/messages or other restricted endpoints originating from API keys that should be scope-blocked.
Requests to Open WebUI containing the x-api-key header where organizational policy standardizes on Authorization: Bearer.
Unexpected model invocation volume associated with API keys flagged as restricted in the Open WebUI admin console.

Detection Strategies

Inventory all Open WebUI instances and identify versions earlier than 0.9.0.
Review web server and reverse proxy access logs for requests bearing the x-api-key header to restricted paths.
Correlate API key identifiers with their administrator-defined scope and flag any responses on endpoints outside that scope.

Monitoring Recommendations

Enable verbose access logging on Open WebUI and forward logs to a centralized SIEM for query and alerting.
Alert on the presence of the x-api-key header if your deployment standard is Authorization: Bearer only.
Track per-key request rates and endpoint distribution to identify keys deviating from their expected usage pattern.

How to Mitigate CVE-2026-45339

Immediate Actions Required

Upgrade Open WebUI to version 0.9.0 or later, which contains the vendor fix.
Rotate any API keys that were issued with endpoint restrictions, since prior usage cannot be retroactively validated.
Audit access logs for the period preceding the upgrade to identify any unauthorized model invocations.

Patch Information

The vendor has released Open WebUI 0.9.0, which enforces endpoint scope checks on both the Authorization and x-api-key authentication paths. Refer to the GitHub Security Advisory GHSA-57q6-fvp4-pqmm for the official remediation notice.

Workarounds

Place a reverse proxy in front of Open WebUI and strip or reject the x-api-key header for restricted routes until the upgrade is applied.
Revoke API keys that rely on endpoint scoping and replace them with full-privilege keys issued only to trusted users.
Restrict network access to the Open WebUI API surface so only authorized clients can reach /api/v1/* endpoints.

bash

# Example NGINX snippet to block the x-api-key header on restricted routes
location /api/v1/messages {
    if ($http_x_api_key != "") {
        return 403;
    }
    proxy_pass http://openwebui_upstream;
}