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 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.
- 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
References
rexpository Reporter
Classic298 Remediation developer
Title: Scheduled automations continue after pending-user deactivation and stored model ACL revocation
Summary
Open WebUI documents
pendingas a zero-access role used for new sign-ups and deactivated users, and normal HTTP routes enforce that withget_verified_user()(which rejectspending), while automation create/update/run routes additionally require thefeatures.automationspermission. Two paths missed that lifecycle gate, so a deactivated (pending) account could keep acting through the background automation scheduler: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.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 topending(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