{"id":"CVE-2026-59226","aliases":["EUVD-2026-42620","GHSA-mvx4-532p-xfm9","PYSEC-2026-3602"],"status":"published","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.","severity":{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00527,"percentile":0.44898,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-285","CWE-862","CWE-863"],"published":"2026-07-09T16:06:55Z","modified":"2026-10-28T02:30:49Z","fixes":[{"ecosystem":"PyPI","package":"open-webui","fixed_in":["0.10.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"open-webui","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.0"},{"fixed":"0.10.0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"open-webui","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.0"},{"fixed":"0.10.0"}]}],"versions":["0.9.0","0.9.1","0.9.2","0.9.3","0.9.4","0.9.5","0.9.6"]},{"source":"osv","ecosystem":"PyPI","package":"open-webui","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.0"},{"fixed":"0.10.0"}]}],"versions":["0.9.0","0.9.1","0.9.2","0.9.3","0.9.4","0.9.5","0.9.6"]}],"products":[{"vendor":"open-webui","product":"open-webui"},{"vendor":"openwebui","product":"open_webui"}],"references":[{"url":"https://github.com/open-webui/open-webui/security/advisories/GHSA-mvx4-532p-xfm9","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/open-webui/open-webui/pull/26047","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/open-webui/open-webui/commit/920b655f4689e2118de928fbc936f6ebd4fed396","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/open-webui/open-webui/releases/tag/v0.10.0","tags":["x_refsource_MISC","Product","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59226","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-mvx4-532p-xfm9","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/59xxx/CVE-2026-59226.json","tags":["advisory"]},{"url":"https://github.com/open-webui/open-webui","tags":["package"]},{"url":"https://pypi.org/project/open-webui","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-59226","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.","status":"published","published":"2026-07-09T16:06:55.927Z","modified":"2026-07-09T18:08:30.89Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low","assessor":"cna"}],"cwes":["CWE-285","CWE-862","CWE-863"],"updated_at":"2026-11-02T14:19:58.560602Z"}],"euvd":[{"id":"EUVD-2026-42620","description":"Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.","status":"published","published":"2026-07-09T16:06:55Z","modified":"2026-07-09T18:08:30Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"updated_at":"2026-11-02T18:20:03.742277Z"}],"ghsa":[{"id":"GHSA-mvx4-532p-xfm9","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"**Title:** Scheduled automations continue after pending-user deactivation and stored model ACL revocation\n\n### Summary\n\nOpen 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:\n\n1. **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.\n2. **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`.\n\nNet 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.\n\n### Impact\n\nA `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.\n\n### Patched\n\nIn 0.10.0:\n\n- `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.\n- `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.\n\n### Credits\n\n@rexpository","status":"published","published":"2026-07-24T16:55:30Z","modified":"2026-07-24T16:55:33Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-285","CWE-862","CWE-863"],"updated_at":"2026-11-02T14:40:52.46233Z"}],"nvd":[{"id":"CVE-2026-59226","description":"Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.","status":"published","published":"2026-07-09T17:17:04.067Z","modified":"2026-07-10T02:42:18.063Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low","assessor":"secondary"},{"version":"3.1","score":4.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"primary"}],"cwes":["CWE-285","CWE-862","CWE-863"],"updated_at":"2026-11-02T14:12:28.4135Z"}],"osv":[{"id":"CVE-2026-59226","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.","status":"published","published":"2026-07-09T16:06:55.927Z","modified":"2026-10-28T02:30:49.637749032Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-285","CWE-862","CWE-863"],"updated_at":"2026-11-02T15:45:12.496548Z"},{"id":"GHSA-mvx4-532p-xfm9","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"**Title:** Scheduled automations continue after pending-user deactivation and stored model ACL revocation\n\n### Summary\n\nOpen 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:\n\n1. **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.\n2. **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`.\n\nNet 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.\n\n### Impact\n\nA `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.\n\n### Patched\n\nIn 0.10.0:\n\n- `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.\n- `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.\n\n### Credits\n\n@rexpository","status":"published","published":"2026-07-24T16:55:30Z","modified":"2026-08-04T14:40:37.647455779Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-285","CWE-862","CWE-863"],"updated_at":"2026-11-02T15:46:52.170928Z"},{"id":"PYSEC-2026-3602","title":"Open WebUI: Scheduled automations continue after pending-user deactivation and stored model ACL revocation","description":"**Title:** Scheduled automations continue after pending-user deactivation and stored model ACL revocation\n\n### Summary\n\nOpen 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:\n\n1. **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.\n2. **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`.\n\nNet 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.\n\n### Impact\n\nA `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.\n\n### Patched\n\nIn 0.10.0:\n\n- `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.\n- `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.\n\n### Credits\n\n@rexpository","status":"published","published":"2026-08-04T11:34:42.461003Z","modified":"2026-08-04T14:30:28.965011814Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"updated_at":"2026-11-02T15:52:56.847083Z"}]}}