Free AI Safety Workshop — in collaboration with explainx.aiSave your seat
AgentbeamBeta
AI agent vulnerability · Open WebUI

CVE-2026-59226: Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation

lowCVSS 3.1 3.1GHSA-mvx4-532p-xfm9

Title: Scheduled automations continue after pending-user deactivation and stored model ACL revocation Summary Open WebUI documents pending as a zero-access role used for new sign-ups and deactivated users, and normal HTTP routes enforce that with getverifieduser() (which rejects pending), while automation create/update/run routes additionally require the features.automations permission.

Published Jul 24, 2026

Affected packages

open-webui

Ecosystem
PyPI
Affected
>= 0.9.0, < 0.10.0
Fixed in
0.10.0
Check
pip show open-webui

Advisory details

From the GitHub Advisory Database (CC BY 4.0).

Title: Scheduled automations continue after pending-user deactivation and stored model ACL revocation

Summary

Open WebUI documents pending as a zero-access role used for new sign-ups and deactivated users, and normal HTTP routes enforce that with get_verified_user() (which rejects pending), while automation create/update/run routes additionally require the features.automations permission. Two paths missed that lifecycle gate, so a deactivated (pending) account could keep acting through the background automation scheduler:

  1. Scheduler did not re-gate the owner. When a stored automation became due, execute_automation() rehydrated the owner with Users.get_user_by_id(...) and re-entered the chat completion pipeline without re-checking that the owner was still user/admin or still held features.automations. A still-active automation therefore kept running after its owner was deactivated.
  2. Model ACL only enforced for exact role `user`. check_model_access() applied private-model grants only when user.role == "user", so a pending principal fell through a branch that denies a normal non-owner user.

Net effect: a deactivated account could continue scheduled chat generation through the background worker, consuming the operator's configured model-provider credentials and reaching a stored automation model ID that its current role/ACL state would no longer permit through normal routes.

Impact

A pending/deactivated account continues to execute due scheduled automations after its access has been revoked, consuming the operator's provider credentials, quota and shared capacity, and bypassing the private-model ACL for the automation's stored model ID. Exploitation requires a previously created active automation and a later transition to pending (deactivation or approval rollback), so it is bounded and not interactive. It does not grant unauthenticated access, account takeover, code execution, or cross-user data exfiltration.

Patched

In 0.10.0:

  • execute_automation() aborts and records an error unless the rehydrated owner is still user or admin and (for non-admins) still holds features.automations, so a deactivated or de-permissioned owner's due automation no longer runs.
  • check_model_access() enforces model ACLs for every non-admin role rather than only the exact role user, so a pending or otherwise unrecognised role no longer falls through.

Credits

@rexpository

Credited to rexpository, Classic298.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology

More Open WebUI vulnerabilities

All Open WebUI entries