CVE-2026-45339: Open WebUI API key restriction

Q: Is CVE-2026-45339 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-45339, increasing the risk of exploitation.

Q: How to fix CVE-2026-45339?

1. Patch immediately: upgrade Open WebUI to v0.9.0 — this is the only complete remediation. 2. Until patched: do not rely on API key endpoint restrictions as a security control; treat all issued keys as having full endpoint access regardless of configured restrictions. 3. Enforce access boundaries at the network or reverse proxy layer (Nginx/Caddy ACLs, firewall rules) by source IP or mTLS in place of endpoint restrictions. 4. Audit and revoke API keys issued with restrictions — those restrictions are currently non-functional and should not be communicated to key holders as active controls. 5. Review API access logs for requests using the `x-api-key` header to endpoints that should have been restricted — anomalous use of this header variant may indicate bypass attempts. 6. In multi-tenant deployments, consider isolating tenant access via separate Open WebUI instances or network segments until the patch is applied and verified.

Q: What systems are affected by CVE-2026-45339?

This vulnerability affects the following AI/ML architecture patterns: LLM gateways and API proxies, Multi-user LLM interfaces, Enterprise AI platforms with RBAC, Self-hosted AI model serving.

Q: What is the CVSS score for CVE-2026-45339?

CVE-2026-45339 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.31%.

CISO Take

Open WebUI's API key permission model contains a complete authorization bypass — any API key with configured endpoint restrictions is trivially circumvented by presenting the same key via the `x-api-key` header instead of `Authorization: Bearer`, granting full access to otherwise-blocked endpoints including LLM completions and potentially admin functionality. This silently invalidates endpoint-based access controls across all Open WebUI deployments on v0.8.12 or earlier, directly affecting organizations using key scoping for role separation in multi-user LLM gateway deployments. While rated CVSS 6.5 (Medium) and absent from CISA KEV, the bypass requires zero technical sophistication — a single HTTP header substitution with a legitimately issued key — making it immediately actionable for any insider or compromised key holder. Upgrade to Open WebUI v0.9.0 immediately; until patched, treat all API keys as having unrestricted endpoint access and enforce boundaries at the network or reverse proxy layer instead.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium CVSS (6.5) understates the operational impact for organizations relying on Open WebUI's API key endpoint restrictions as a meaningful security boundary. The bypass is trivial — one HTTP header substitution — and requires only a valid API key (PR:H per CVSS), limiting exposure to authorized users or compromised key holders. However, the failure is complete: endpoint restrictions provide zero security value until patched. Risk is elevated in enterprise multi-tenant deployments where key scoping enforces role separation between users, services, or departments accessing shared LLM infrastructure. No public exploit or Nuclei template exists, and there is no CISA KEV entry, but the technique is trivially discoverable through routine API exploration. With 91 prior CVEs in the same package, defenders should treat open-webui as a high-attention component.

How does the attack unfold?

Initial Access

Attacker obtains a valid Open WebUI API key — either as a legitimately provisioned user, insider, or via credential theft — where the key has administrator-configured endpoint restrictions.

AML.T0012

Restriction Discovery

Attacker probes the API and observes a 403 response when using the Authorization header against a restricted endpoint, then tests the x-api-key header variant and receives a 200 response.

AML.T0049

Authorization Bypass

By substituting 'x-api-key: sk-...' for 'Authorization: Bearer sk-...', the attacker bypasses all endpoint restriction checks; the restriction logic is skipped entirely and the key authenticates successfully.

AML.T0091.000

Impact

Attacker invokes unrestricted LLM completions on any configured model, consuming organizational AI credits beyond authorized limits and potentially accessing admin endpoints to enumerate users or exfiltrate system configuration.

AML.T0034

Initial Access

Attacker obtains a valid Open WebUI API key — either as a legitimately provisioned user, insider, or via credential theft — where the key has administrator-configured endpoint restrictions.

AML.T0012

Restriction Discovery

Attacker probes the API and observes a 403 response when using the Authorization header against a restricted endpoint, then tests the x-api-key header variant and receives a 200 response.

AML.T0049

Authorization Bypass

By substituting 'x-api-key: sk-...' for 'Authorization: Bearer sk-...', the attacker bypasses all endpoint restriction checks; the restriction logic is skipped entirely and the key authenticates successfully.

AML.T0091.000

Impact

Attacker invokes unrestricted LLM completions on any configured model, consuming organizational AI credits beyond authorized limits and potentially accessing admin endpoints to enumerate users or exfiltrate system configuration.

AML.T0034

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	<= 0.8.12	`0.9.0`
143.3K Pushed 8d ago 77% patched ~5d to patch Full package profile →
Open WebUI	pip	—	No patch
143.3K Pushed 8d ago 77% patched ~5d to patch Full package profile →

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 23% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR High

UI None

S Unchanged

C High

I High

A None

What should I do?

6 steps

Patch immediately: upgrade Open WebUI to v0.9.0 — this is the only complete remediation.
Until patched: do not rely on API key endpoint restrictions as a security control; treat all issued keys as having full endpoint access regardless of configured restrictions.
Enforce access boundaries at the network or reverse proxy layer (Nginx/Caddy ACLs, firewall rules) by source IP or mTLS in place of endpoint restrictions.
Audit and revoke API keys issued with restrictions — those restrictions are currently non-functional and should not be communicated to key holders as active controls.
Review API access logs for requests using the x-api-key header to endpoints that should have been restricted — anomalous use of this header variant may indicate bypass attempts.
In multi-tenant deployments, consider isolating tenant access via separate Open WebUI instances or network segments until the patch is applied and verified.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass API AML.T0034 - Cost Harvesting AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.2 - AI risk management — access control

NIST AI RMF

GOVERN 6.1 - Policies and procedures for AI risk are established and followed

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-45339?

Open WebUI's API key permission model contains a complete authorization bypass — any API key with configured endpoint restrictions is trivially circumvented by presenting the same key via the `x-api-key` header instead of `Authorization: Bearer`, granting full access to otherwise-blocked endpoints including LLM completions and potentially admin functionality. This silently invalidates endpoint-based access controls across all Open WebUI deployments on v0.8.12 or earlier, directly affecting organizations using key scoping for role separation in multi-user LLM gateway deployments. While rated CVSS 6.5 (Medium) and absent from CISA KEV, the bypass requires zero technical sophistication — a single HTTP header substitution with a legitimately issued key — making it immediately actionable for any insider or compromised key holder. Upgrade to Open WebUI v0.9.0 immediately; until patched, treat all API keys as having unrestricted endpoint access and enforce boundaries at the network or reverse proxy layer instead.

Is CVE-2026-45339 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-45339, increasing the risk of exploitation.

How to fix CVE-2026-45339?

1. Patch immediately: upgrade Open WebUI to v0.9.0 — this is the only complete remediation. 2. Until patched: do not rely on API key endpoint restrictions as a security control; treat all issued keys as having full endpoint access regardless of configured restrictions. 3. Enforce access boundaries at the network or reverse proxy layer (Nginx/Caddy ACLs, firewall rules) by source IP or mTLS in place of endpoint restrictions. 4. Audit and revoke API keys issued with restrictions — those restrictions are currently non-functional and should not be communicated to key holders as active controls. 5. Review API access logs for requests using the `x-api-key` header to endpoints that should have been restricted — anomalous use of this header variant may indicate bypass attempts. 6. In multi-tenant deployments, consider isolating tenant access via separate Open WebUI instances or network segments until the patch is applied and verified.

What systems are affected by CVE-2026-45339?

This vulnerability affects the following AI/ML architecture patterns: LLM gateways and API proxies, Multi-user LLM interfaces, Enterprise AI platforms with RBAC, Self-hosted AI model serving.

What is the CVSS score for CVE-2026-45339?

CVE-2026-45339 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.31%.

What is the AI security impact?

Affected AI Architectures

LLM gateways and API proxiesMulti-user LLM interfacesEnterprise AI platforms with RBACSelf-hosted AI model serving

MITRE ATLAS Techniques

AML.T0034 Cost Harvesting

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.2

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

### Summary Open WebUI allows admins to restrict which API endpoints an API key can access. When an API key is restricted from `/api/v1/messages`, requests using the `Authorization: Bearer sk-...` header are correctly blocked with 403. However, the same key sent via the `x-api-key` header bypasses the restriction entirely — the request is authenticated, the model is invoked, and a full response is returned. ### Details Open WebUI's Anthropic-compatible API path accepts authentication via `x-api-key` header (standard for the Anthropic API). The endpoint restriction check only applies to keys presented via the `Authorization` header. When the same `sk-...` key is supplied in `x-api-key`, the restriction check is skipped but the key is still valid for authentication. This means any API key, regardless of its configured endpoint restrictions, can access any API endpoint by simply using `x-api-key` instead of `Authorization`. ### PoC **Verified against Open WebUI v0.8.11.** **Setup:** Admin creates a user with an API key that has endpoint restrictions (not allowed on `/api/v1/messages`). A mock OpenAI-compatible model (`mock-model`) is configured. ```bash API_KEY="sk-dc56016d720e49ba9e95584d602b79bb" # Test 1: Authorization header — BLOCKED (endpoint restriction enforced) curl -s -X POST http://target:8080/api/v1/messages \ -H "Authorization: Bearer $API_KEY" \ -H 'Content-Type: application/json' \ -d '{"model":"mock-model","messages":[{"role":"user","content":"via Authorization header"}]}' # Test 2: x-api-key header — BYPASS (same key, restriction skipped) curl -s -X POST http://target:8080/api/v1/messages \ -H "x-api-key: $API_KEY" \ -H 'Content-Type: application/json' \ -d '{"model":"mock-model","messages":[{"role":"user","content":"via x-api-key header"}]}' ``` **Verified output:** ``` # Authorization header: {"detail":"API key not allowed to access this endpoint."} # x-api-key header (SAME key): {"id":"chatcmpl-mock","type":"message","role":"assistant","content":[{"type":"text","text":"MOCK-CHAT-RESPONSE"}],"model":"mock-model","usage":{"input_tokens":1,"output_tokens":1}} ``` The same API key is rejected via `Authorization` (403) but fully processed via `x-api-key` (200 with model response). ### Impact Any API key with endpoint restrictions can bypass those restrictions by using the `x-api-key` header instead of `Authorization`. This undermines the entire API key permission model: - Keys restricted from chat/completion endpoints can still send messages and receive LLM responses - Keys restricted from admin endpoints may access admin functionality - The operator's intended access control is silently ineffective - API credit spend cannot be controlled through endpoint restrictions

Exploitation Scenario

A developer or automated service with a legitimately issued Open WebUI API key — restricted by an admin from accessing `/api/v1/messages` to prevent unauthorized LLM usage or credit abuse — discovers that switching the HTTP header from `Authorization: Bearer sk-...` to `x-api-key: sk-...` bypasses the restriction entirely and receives a full LLM response. The attacker now sends arbitrary prompts to any model configured in the Open WebUI instance, consuming organizational LLM credits, potentially exfiltrating conversation history accessible through the API, and pivoting to admin-level endpoints to enumerate users or exfiltrate system configuration. Because the key is legitimately issued and authenticated, the malicious requests appear indistinguishable from authorized usage in standard API logs, providing no immediate detection signal.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.