CVE-2026-59226Low· 3.1▾ SunlitOpen WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation
▾ Sunlit zone — Low / medium · no exploitation signal
impact 17.1 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 24.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
Title: Scheduled automations continue after pending-user deactivation and stored model ACL revocation
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:
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.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.
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.
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.@rexpository
open-webui >= 0.9.0, < 0.10.0Upgrade to a patched release:
open-webui 0.10.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-59227Medium· 4.3Open WebUI: POST /api/v1/images/edit bypasses the global image-edit switch and the per-user image-generation permission
CVE-2026-59217Medium· 4.3Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)
CVE-2026-59212Medium· 5.4Open WebUI: Model meta.knowledge read-only file access can be upgraded to file write/delete
CVE-2026-59225Medium· 5.4Open WebUI: Arena task endpoints can bypass underlying model access controls
CVE-2026-59714High· 7.1Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform
CVE-2026-54012High· 7.1Open WebUI: Forged model meta.knowledge allows cross-user file read and deletion