GHSA-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 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