CVE-2026-59226: Open WebUI deactivated users retain

CISO Take

Open WebUI's scheduled automation engine rehydrates an automation's owner from a stale reference instead of re-verifying the account is still active or still holds the features.automations permission, and a companion check (check_model_access) only enforces private-model grants for an exact role match — together letting a deactivated or still-pending user's scheduled automation keep executing against models it should no longer be able to reach. This is a low-severity access-control gap (CVSS 3.1, availability-only impact per the C:N/I:N/A:L vector) rather than a data-exposure or code-execution bug, and its EPSS score of 0.3% reflects that exploitation requires an authenticated low-privileged account plus a specific offboarding-timing condition (AC:H) — it is not in CISA KEV and has no public exploit or Nuclei template. The practical exposure is in offboarding hygiene: Open WebUI is a widely self-hosted LLM front-end with 130 other tracked CVEs against the package, so any org using account deactivation as an access-revocation control should not assume it fully cuts off model access while automations remain in place. Upgrade to Open WebUI 0.10.0, which re-validates owner activity status and enforces role-exact grants on every automation run; until then, manually audit and disable scheduled automations owned by deactivated or pending users as part of offboarding.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Overall risk is low. The CVSS 3.1 score of 3.1 reflects high attack complexity and a requirement for low (but authenticated) privileges, with impact confined to availability (A:L) — confidentiality and integrity are unaffected per the vector. There is no evidence of active exploitation: the CVE is not in CISA KEV, has no public exploit, and no Nuclei scanning template exists. EPSS is 0.3%, consistent with a narrow, process-dependent access-control flaw rather than a broadly exploitable bug. The main risk driver is not technical sophistication but operational: it undermines the assumption that deactivating a user account fully revokes that user's downstream automated access to AI models.

How does the attack unfold?

Automation setup

A user (later deactivated or left in pending status) creates a scheduled automation with access to a private/restricted AI model.

Access-control bypass on execution

execute_automation rehydrates the automation owner without rechecking active status, and check_model_access only enforces the private-model grant for an exact role match, so the run is permitted despite the owner's changed status.

AML.T0040

Continued unauthorized model access

The automation keeps executing on its schedule, letting a deactivated or still-pending user retain indirect, ongoing access to a model they should no longer be entitled to use.

AML.T0040

Automation setup

A user (later deactivated or left in pending status) creates a scheduled automation with access to a private/restricted AI model.

Access-control bypass on execution

execute_automation rehydrates the automation owner without rechecking active status, and check_model_access only enforces the private-model grant for an exact role match, so the run is permitted despite the owner's changed status.

AML.T0040

Continued unauthorized model access

The automation keeps executing on its schedule, letting a deactivated or still-pending user retain indirect, ongoing access to a model they should no longer be entitled to use.

AML.T0040

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	>= 0.9.0, < 0.10.0	`0.10.0`
149.6K 4 dependents Pushed 3d ago 81% patched ~6d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1

3.1 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 22% 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 Low

UI None

S Unchanged

C None

I None

A Low

What should I do?

1 step

1) Patch: upgrade to open-webui >= 0.10.0, which rechecks automation-owner active status and features.automations entitlement at execution time and tightens check_model_access role validation. 2) Workaround until patched: manually inventory all scheduled automations and cross-reference owners against the active-user list; disable or delete automations owned by deactivated or still-pending accounts. 3) Detection: review automation execution/audit logs for runs attributed to accounts that are deactivated or pending, and monitor for private-model queries originating from automations tied to non-active owners. 4) Process: fold 'revoke/delete owned automations' into the standard offboarding checklist rather than relying solely on account deactivation.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Agent Model AML.T0040 - AI Model Inference API Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.9 - AI system operation and monitoring

NIST AI RMF

MANAGE-2.3 - Mechanisms are in place and applied to supersede, disengage, or deactivate AI systems

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-59226?

Open WebUI's scheduled automation engine rehydrates an automation's owner from a stale reference instead of re-verifying the account is still active or still holds the features.automations permission, and a companion check (check_model_access) only enforces private-model grants for an exact role match — together letting a deactivated or still-pending user's scheduled automation keep executing against models it should no longer be able to reach. This is a low-severity access-control gap (CVSS 3.1, availability-only impact per the C:N/I:N/A:L vector) rather than a data-exposure or code-execution bug, and its EPSS score of 0.3% reflects that exploitation requires an authenticated low-privileged account plus a specific offboarding-timing condition (AC:H) — it is not in CISA KEV and has no public exploit or Nuclei template. The practical exposure is in offboarding hygiene: Open WebUI is a widely self-hosted LLM front-end with 130 other tracked CVEs against the package, so any org using account deactivation as an access-revocation control should not assume it fully cuts off model access while automations remain in place. Upgrade to Open WebUI 0.10.0, which re-validates owner activity status and enforces role-exact grants on every automation run; until then, manually audit and disable scheduled automations owned by deactivated or pending users as part of offboarding.

Is CVE-2026-59226 actively exploited?

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

How to fix CVE-2026-59226?

1) Patch: upgrade to open-webui >= 0.10.0, which rechecks automation-owner active status and features.automations entitlement at execution time and tightens check_model_access role validation. 2) Workaround until patched: manually inventory all scheduled automations and cross-reference owners against the active-user list; disable or delete automations owned by deactivated or still-pending accounts. 3) Detection: review automation execution/audit logs for runs attributed to accounts that are deactivated or pending, and monitor for private-model queries originating from automations tied to non-active owners. 4) Process: fold 'revoke/delete owned automations' into the standard offboarding checklist rather than relying solely on account deactivation.

What systems are affected by CVE-2026-59226?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, model serving.

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

CVE-2026-59226 has a CVSS v3.1 base score of 3.1 (LOW). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmodel serving

MITRE ATLAS Techniques

AML.T0040 AI Model Inference API Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.

Exploitation Scenario

A contractor or employee with a pending or later-deactivated Open WebUI account creates a scheduled automation configured to query a private, access-restricted model as part of their normal work. When their account is deactivated during offboarding (or never fully approved, staying in pending state), the automation is not disabled. Because execute_automation rehydrates the automation using a stale owner reference instead of rechecking whether that owner is still active, and check_model_access only validates the exact role rather than active status, the scheduled job keeps running unattended — continuing to query the private model on the former user's behalf and effectively preserving their access to model outputs after their credentials should have been revoked.

Weaknesses (CWE)

CWE-285 Improper Authorization Primary CWE-862 Missing Authorization Primary CWE-863 Incorrect Authorization Primary CWE-285 Improper Authorization CWE-862 Missing Authorization CWE-863 Incorrect Authorization

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

[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) 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 you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply 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.

Source: MITRE CWE corpus.