Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation
PYSEC-2026-3602 · CVE-2026-59226 · GHSA-mvx4-532p-xfm9
Published · Modified
AI SAST
Find this class of vulnerability in your own code
Corgea's AI-native static analysis detects vulnerabilities like this one across your repositories, ranks them by exploitability, and returns review-ready fixes.
Description
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:
- Scheduler did not re-gate the owner. When a stored automation became due,
execute_automation()rehydrated the owner withUsers.get_user_by_id(...)and re-entered the chat completion pipeline without re-checking that the owner was stilluser/adminor still heldfeatures.automations. A still-active automation therefore kept running after its owner was deactivated. - Model ACL only enforced for exact role
user.check_model_access()applied private-model grants only whenuser.role == "user", so apendingprincipal fell through a branch that denies a normal non-owneruser.
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 stilluseroradminand (for non-admins) still holdsfeatures.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 roleuser, so apendingor otherwise unrecognised role no longer falls through.
Credits
@rexpository
References
- WEB https://github.com/open-webui/open-webui/security/advisories/GHSA-mvx4-532p-xfm9
- ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-59226
- WEB https://github.com/open-webui/open-webui/pull/26047
- WEB https://github.com/open-webui/open-webui/commit/920b655f4689e2118de928fbc936f6ebd4fed396
- PACKAGE https://github.com/open-webui/open-webui
- WEB https://github.com/open-webui/open-webui/releases/tag/v0.10.0
- PACKAGE https://pypi.org/project/open-webui
- ADVISORY https://github.com/advisories/GHSA-mvx4-532p-xfm9
Ready to move
Start Securing
Free, no credit card | First findings in minutes