https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 05:13:31 +0000 https://cve.radiocsirt.org/vuln/cve-2026-59226 <p><strong>Affected:</strong> open-webui</p> <p>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.</p> <p><strong>Affected:</strong> open-webui</p> <p>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.</p> https://cve.radiocsirt.org/vuln/cve-2026-59226 https://cve.radiocsirt.org/vuln/ghsa-mvx4-532p-xfm9 <p><strong>Affected:</strong> PyPI: open-webui</p> <p>**Title:** Scheduled automations continue after pending-user deactivation and stored model ACL revocation</p> <p>### Summary</p> <p>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:</p> <p>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 == &#34;user&#34;`, so a `pending` principal fell through a branch that denies a normal non-owner `user`.</p> <p>Net effect: a deactivated account could continue scheduled chat generation through the background worker, consuming the operator&#39;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.</p> <p>### Impact</p> <p>A `pending`/deactivated account continue…</p> <p><strong>Affected:</strong> PyPI: open-webui</p> <p>**Title:** Scheduled automations continue after pending-user deactivation and stored model ACL revocation</p> <p>### Summary</p> <p>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:</p> <p>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 == &#34;user&#34;`, so a `pending` principal fell through a branch that denies a normal non-owner `user`.</p> <p>Net effect: a deactivated account could continue scheduled chat generation through the background worker, consuming the operator&#39;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.</p> <p>### Impact</p> <p>A `pending`/deactivated account continue…</p> https://cve.radiocsirt.org/vuln/ghsa-mvx4-532p-xfm9