CVE-2026-59226: Open WebUI Deactivated User Automation Execution Flaw

Technical summary

The vulnerability involves two related authorization defects in Open WebUI's automation and model access layers. The execute_automation function rehydrates stored automation owners from persistent storage without re-validating their current active status or confirming they retain the features.automations capability. Similarly, check_model_access enforces private-model grants only against the exact user role at execution time, rather than validating the user's current operational state. This allows accounts marked as deactivated or pending to retain execution privileges for previously scheduled tasks. The issue affects all versions from 0.9.0 up to but not including 0.10.0.

Business impact

Organizations running Open WebUI as a self-hosted AI platform face insider risk and data access control degradation. When users are offboarded or deactivated, their scheduled automations may continue executing in the background, potentially accessing sensitive models or performing unintended operations. This extends the effective account lifecycle beyond administrative intent and complicates audit trails. While the CVSS score is low, the impact depends on what automations are configured and what sensitive models exist in the deployment.

Affected systems

Open WebUI versions 0.9.0 through 0.9.x are vulnerable. Version 0.10.0 and later are patched. Any self-hosted Open WebUI deployment within this version range requires assessment, particularly installations with configured automations or restricted model access policies.

Exploitability

Exploitation requires an existing Open WebUI user account that has been deactivated or marked pending by an administrator. The attacker must have created automations prior to account deactivation, or the account must have the ability to create automations before being disabled. No network-based exploitation is possible; this is an internal privilege and state-management issue. The CVSS vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects the need for local authentication and a high complexity barrier, limiting practical attack scenarios.

Remediation

Upgrade Open WebUI to version 0.10.0 or later. The patched version re-validates automation owner status and reintroduces proper authorization checks before executing stored automations and granting model access. Organizations should also audit existing automations and review deactivated user accounts to identify any orphaned or unintended scheduled tasks.

Patch guidance

Apply Open WebUI 0.10.0 or a later stable release. Verify the patch by checking the installed version in the Open WebUI admin interface or via the application logs. Test the upgrade in a non-production environment first to confirm automations continue to function correctly for active users. Consider scheduling the upgrade during a maintenance window if automations are business-critical.

Detection guidance

Review Open WebUI audit logs for automation executions attributed to deactivated or pending users. Cross-reference the automation execution timestamps with user account status changes to identify suspicious patterns. Monitor for model access requests from users whose accounts are not in active status. If available, enable verbose logging in Open WebUI to capture authorization decision details.

Why prioritize this

Although the CVSS score is low, the vulnerability directly undermines access control policies that are typically implemented for compliance and operational security. Deactivated users retaining execution privileges creates an audit liability and may violate the principle of least privilege. Prioritize patching in environments where strict user lifecycle management is a compliance requirement or where automations handle sensitive data.

Risk score, explained

The CVSS 3.1 score of 3.1 (LOW) reflects a narrow attack surface: the attacker must be a registered user (PR:L) with an account that was previously active enough to create automations, then have that account deactivated. The attack does not affect confidentiality (C:N) and offers no direct integrity compromise (I:N), only availability of the automation feature (A:L). The high complexity (AC:H) accounts for the prerequisite of account deactivation by an administrator and the limited window of opportunity.

Frequently asked questions