Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-09T22:18:46.720Z",
  "pubdate": "2026-09-09T22:18:46.720Z",
  "executiveSummary": "Open WebUI versions 0.6.41 through 0.11.1 are susceptible to an improper neutralization of special elements in SQL queries within its OAuth and SCIM authentication mechanisms. The vulnerability stems from the use of insecure substring matching when querying SQLite databases, specifically within the functions get_user_by_oauth_sub and get_user_by_scim_external_id located in backend/open_webui/models/users.py.\nThe vulnerability allows an unauthenticated or authenticated attacker to perform account takeover by providing a crafted OAuth subject identifier containing SQL wildcard characters (such as '%' or '_').\nThis flaw enables the attacker to manipulate the backend query logic to return an unintended database record—most notably an administrator account—resulting in the issuance of an authenticated session for that target identity. The risk profile is critical, as it bypasses standard identity provider validation. The impact is limited to deployments utilizing SQLite, while PostgreSQL environments remain unaffected. Remediation requires an immediate upgrade to version 0.11.1 or higher to ensure proper parameterization and input sanitization during user retrieval operations.",
  "technicalDetails": "The root cause of this vulnerability is the implementation of unsanitized input within SQL query filters using the LIKE operator in the SQLite backend. Specifically, the functions 'get_user_by_oauth_sub' and 'get_user_by_scim_external_id' within 'backend/open_webui/models/users.py' process external inputs from OAuth or SCIM identity providers without escaping SQL wildcard characters.\nIn SQLite, the LIKE operator treats '%' as a multi-character wildcard and '_' as a single-character wildcard. Because these input fields are intended to identify unique user identities, the application logic assumes a direct, exact match. However, when the database performs a LIKE match on a malicious string containing these wildcards, the search pattern may match multiple records or, more critically, return the first record that satisfies the pattern rather than the specific intended user ID.\nThe attack flow begins when an attacker initiates an authentication process via an OAuth provider or SCIM service that they control or can manipulate. The attacker crafts a malicious 'sub' (subject) or 'external_id' claim containing SQLite wildcard characters. For example, by submitting a subject claim composed of a single '%' character, the application's query effectively becomes 'SELECT * FROM users WHERE oauth_sub LIKE '%'.'\nUnder these conditions, the database query returns the first account present in the users table, which is frequently the administrator account created during initial deployment. The application logic mistakenly associates this returned administrator database record with the attacker's current session. Consequently, the backend issues an authenticated session token to the attacker, effectively granting them full administrative privileges without legitimate credentials for that account.\nThis vulnerability is restricted to environments using SQLite, as the dialect-specific behavior of the LIKE operator allows for this pattern-matching exploitation. Because the vulnerability resides in the identity verification layer, it bypasses authorization controls and results in complete system compromise. The issue was resolved in version 0.11.1 by ensuring that inputs are strictly handled and sanitized to prevent wildcard interpretation in identity lookup functions."
}