CVE-2026-87016: Open WebUI OAuth wildcard bug hijacks

Q: Is CVE-2026-87016 actively exploited?

No confirmed active exploitation of CVE-2026-87016 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-87016?

Upgrade to Open WebUI 0.11.1 or later immediately on any SQLite-backed deployment. If immediate patching isn't possible, disable OAuth/SCIM login as a stopgap, or migrate the backend database to PostgreSQL, which is confirmed unaffected. Audit `get_user_by_oauth_sub`/`get_user_by_scim_external_id` call logs and IdP-issued subject/external-ID claims for '%' or '_' characters, review recent admin logins for unfamiliar OAuth identities, and rotate admin session tokens and any exposed model API keys after patching.

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

This vulnerability affects the following AI/ML architecture patterns: Self-hosted LLM chat platforms, RAG pipelines, SSO/OAuth-integrated AI platforms, Multi-tenant AI deployments.

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

CVE-2026-87016 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.35%.

CISO Take

Open WebUI's OAuth and SCIM identity lookup used a JSON "contains" match that SQLite silently compiled into a plain LIKE substring comparison, so an OAuth subject or SCIM external ID containing "%" or "_" wildcard characters could match a completely different stored user record — including an administrator — and the attacker would be issued that account's session. This is a full authentication-bypass and account-takeover primitive (CVSS 8.1, C:H/I:H/A:H) on a self-hosted AI chat platform that typically holds every user's conversation history, connected model API keys, and uploaded RAG documents, so an attacker who lands an admin session gets both full application control and a pivot into whatever LLM backends and credentials Open WebUI proxies. There is no evidence of active exploitation — it's not in CISA KEV, has no EPSS score, and no public PoC or Nuclei template exists — and the flaw is scoped to SQLite-backed deployments only, since PostgreSQL is unaffected, which limits blast radius mostly to smaller self-hosted or trial instances rather than Postgres-backed production clusters. Attack complexity is rated high because it requires OAuth or SCIM provisioning to be enabled plus a subject value the attacker can influence, but that's a realistic bar for any org federating Open WebUI to an identity provider it doesn't fully control. Patch every SQLite-backed instance to Open WebUI 0.11.1 immediately, and in the interim audit logs for OAuth/SCIM subject claims containing "%" or "_" and verify no unexpected admin logins originated from unfamiliar identities.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk in a narrow but serious slice of deployments. Impact is severe (full admin account takeover, C:H/I:H/A:H) but exploitability is bounded: it only affects SQLite-backed installs with OAuth or SCIM provisioning enabled, and the attacker needs some ability to influence their own subject/external-ID claim (typically via a self-service or federated IdP). No active exploitation signal exists (no KEV listing, no EPSS score, no public exploit or scanner template), so this reads as a disclosed logic flaw rather than an in-the-wild threat today — but it's trivial to weaponize once understood, since it requires no special AI/ML knowledge, only crafting a wildcard string.

How does the attack unfold?

Initial Access

Attacker obtains or controls an OAuth/SCIM identity whose subject or external-ID claim they can set to include SQL wildcard characters ('%' or '_').

AML.T0049

Identity Confusion

Open WebUI's user lookup on SQLite compiles the intended exact-match JSON query into a LIKE substring match, causing the crafted claim to match a different stored user record.

Session Issuance

The application incorrectly binds the login to the matched account — potentially an administrator — and issues that account's active session to the attacker without a credential check.

AML.T0012

Impact

Attacker gains full administrative control of the Open WebUI instance: user management, connected model API keys, and all users' conversation history and RAG data.

AML.T0057

Initial Access

Attacker obtains or controls an OAuth/SCIM identity whose subject or external-ID claim they can set to include SQL wildcard characters ('%' or '_').

AML.T0049

Identity Confusion

Open WebUI's user lookup on SQLite compiles the intended exact-match JSON query into a LIKE substring match, causing the crafted claim to match a different stored user record.

Session Issuance

The application incorrectly binds the login to the matched account — potentially an administrator — and issues that account's active session to the attacker without a credential check.

AML.T0012

Impact

Attacker gains full administrative control of the Open WebUI instance: user management, connected model API keys, and all users' conversation history and RAG data.

AML.T0057

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	>= 0.6.41, < 0.11.1	`0.11.1`
151.8K 3 dependents Pushed 7d ago 83% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 29% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade to Open WebUI 0.11.1 or later immediately on any SQLite-backed deployment. If immediate patching isn't possible, disable OAuth/SCIM login as a stopgap, or migrate the backend database to PostgreSQL, which is confirmed unaffected. Audit get_user_by_oauth_sub/get_user_by_scim_external_id call logs and IdP-issued subject/external-ID claims for '%' or '_' characters, review recent admin logins for unfamiliar OAuth identities, and rotate admin session tokens and any exposed model API keys after patching.

How is it classified?

Auth Bypass Privacy Violation Framework API AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

GOVERN-1.5 - Cybersecurity risk management processes are integrated into AI risk management

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-87016?

Open WebUI's OAuth and SCIM identity lookup used a JSON "contains" match that SQLite silently compiled into a plain LIKE substring comparison, so an OAuth subject or SCIM external ID containing "%" or "_" wildcard characters could match a completely different stored user record — including an administrator — and the attacker would be issued that account's session. This is a full authentication-bypass and account-takeover primitive (CVSS 8.1, C:H/I:H/A:H) on a self-hosted AI chat platform that typically holds every user's conversation history, connected model API keys, and uploaded RAG documents, so an attacker who lands an admin session gets both full application control and a pivot into whatever LLM backends and credentials Open WebUI proxies. There is no evidence of active exploitation — it's not in CISA KEV, has no EPSS score, and no public PoC or Nuclei template exists — and the flaw is scoped to SQLite-backed deployments only, since PostgreSQL is unaffected, which limits blast radius mostly to smaller self-hosted or trial instances rather than Postgres-backed production clusters. Attack complexity is rated high because it requires OAuth or SCIM provisioning to be enabled plus a subject value the attacker can influence, but that's a realistic bar for any org federating Open WebUI to an identity provider it doesn't fully control. Patch every SQLite-backed instance to Open WebUI 0.11.1 immediately, and in the interim audit logs for OAuth/SCIM subject claims containing "%" or "_" and verify no unexpected admin logins originated from unfamiliar identities.

Is CVE-2026-87016 actively exploited?

No confirmed active exploitation of CVE-2026-87016 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-87016?

Upgrade to Open WebUI 0.11.1 or later immediately on any SQLite-backed deployment. If immediate patching isn't possible, disable OAuth/SCIM login as a stopgap, or migrate the backend database to PostgreSQL, which is confirmed unaffected. Audit `get_user_by_oauth_sub`/`get_user_by_scim_external_id` call logs and IdP-issued subject/external-ID claims for '%' or '_' characters, review recent admin logins for unfamiliar OAuth identities, and rotate admin session tokens and any exposed model API keys after patching.

What systems are affected by CVE-2026-87016?

This vulnerability affects the following AI/ML architecture patterns: Self-hosted LLM chat platforms, RAG pipelines, SSO/OAuth-integrated AI platforms, Multi-tenant AI deployments.

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

CVE-2026-87016 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.35%.

What is the AI security impact?

Affected AI Architectures

Self-hosted LLM chat platformsRAG pipelinesSSO/OAuth-integrated AI platformsMulti-tenant AI deployments

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN-1.5

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.41 until 0.11.1, get_user_by_oauth_sub and get_user_by_scim_external_id in backend/open_webui/models/users.py used JSON contains matching that compiled to SQL LIKE substring matching on SQLite. An OAuth subject containing percent or underscore wildcard characters could resolve to a different stored identity, potentially selecting an administrator account and issuing the attacker that account's session; PostgreSQL deployments were not affected. This issue is fixed in version 0.11.1.

Exploitation Scenario

An attacker with the ability to influence their own OAuth subject claim — for example via self-service signup on a federated IdP, or a malicious insider with IdP account control — sets that claim to include a SQL wildcard such as '%adminuser%' or a single '_' positioned to match an existing stored subject. Because Open WebUI's lookup on SQLite compiles to a LIKE substring match rather than an exact match, the login resolves to the wrong stored identity — potentially an administrator — and the platform issues that admin's active session cookie to the attacker with no credential check, handing over full administrative control of the AI platform.

Weaknesses (CWE)

CWE-155 Improper Neutralization of Wildcards or Matching Symbols Primary CWE-287 Improper Authentication Primary CWE-155 Improper Neutralization of Wildcards or Matching Symbols CWE-287 Improper Authentication

CWE-155 — Improper Neutralization of Wildcards or Matching Symbols: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.

Developers should anticipate that wildcard or matching elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.