Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
Medium4.3CVE-2026-87012 · Published Sep 10, 2026
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| open-webui PyPI | >= 0.9.0, < 0.11.1 | 0.11.1 |
Details and references
# Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value ## Summary Calendar events carry a free-form `meta` object that is stored exactly as submitted, with no validation of the values inside it. The scheduler reads the per-event alert offset out of that object in a single pass that covers every user's upcoming events, and compares it numerically without checking that it is a number. Any verified user could store a text value there, which made the comparison raise and abort the whole pass, so no calendar reminder fired for anyone on the instance while that event stayed inside the lookahead window. ## Preconditions - Calendar is enabled (`ENABLE_CALENDAR` / `calendar.enable`, default `True`). - The attacker is a verified user (role `user` or `admin`) holding the `calendar` feature permission, which is granted to all users by default (`USER_PERMISSIONS_FEATURES_CALENDAR`, default `True`). - The event's start time falls inside the scheduler's one hour lookahead window, so the shared alert pass selects it. No admin access, no shared calendar, no recurrence rule and no open registration are required, an invited account is enough. Deployments running with the calendar disabled, or with the calendar feature permission removed from regular users, are not affected. ## Impact Availability loss on one feature, affecting every user on the instance. While a single event carrying a non-numeric alert value sat in the upcoming window, the shared alert pass raised before emitting anything, so no user received calendar alerts and no event was recorded as alerted. The same events were selected again on the next poll, so the suppression lasted as long as the event stayed in the window, roughly one hour per event, and could be sustained by storing a new one. Every user on a default deployment holds the permission needed to do this. Chat, timers, automations and the HTTP API kept working throughout, and authenticated calendar reads continued to succeed. There is no crash, no code execution, and no access to other users' data. Alerts resumed on their own once the event left the window or was deleted. ## Fix Fixed in https://github.com/open-webui/open-webui/pull/28790, released in 0.11.1. The scheduler now treats any non-numeric alert value as unset and falls back to the default alert offset, so a stored text value can no longer interrupt the pass. Upgrading is sufficient and no configuration change is required. Events already holding a bad value simply revert to the default alert timing. ## Root cause Affected component: the upcoming-event lookup in the calendar event model, which the scheduler's alert pass calls every poll. Affected setup: every build carrying the calendar feature, which was introduced in 0.9.0. Event `meta` is an untyped dictionary and was written to the database exactly as submitted, so nothing on the write path guaranteed that the alert offset was a number. The alert pass then read that value back and compared it numerically on the assumption that the write path had already constrained it, and the loop had no per-event error handling. Because a single background pass serves the whole instance rather than one user at a time, one unusable value from one user aborted the pass for everyone. ## Proof of concept Reported with a scripted reproduction against 0.11.0 (`ghcr.io/open-webui/open-webui:latest`) with the calendar enabled and two ordinary user accounts. The first account created an upcoming event with the alert offset stored as the text `"5"`, the second created a normal upcoming event with a numeric offset. Across several scheduler polls the second user's event was never marked as alerted and no alert was delivered, while the server logged a type error from the alert pass on each poll. Health checks and authenticated calendar reads returned normally during the fault. After the first account's event was deleted, the second user's event was marked as alerted on the next p
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-1287, CWE-754
- Also known as
- CVE-2026-87012
- github.com/open-webui/open-webui/security/advisories/GHSA-v39v-59xw-j98g
- nvd.nist.gov/vuln/detail/CVE-2026-87012
- github.com/open-webui/open-webui/pull/28790
- github.com/open-webui/open-webui/commit/abc69000b33b4894fbd97fc2c962139cf9a8d784
- github.com/open-webui/open-webui
- github.com/open-webui/open-webui/releases/tag/v0.11.1
More Open WebUI advisories
All Open WebUI| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Sep 9 | Open WebUI: Any authenticated user can hang the server via message deletion in a cyclic chat tree CVE-2026-88000Medium6.5fixed in 0.11.1 | Medium6.5 | 0.11.1 |
| Sep 9 | Open WebUI: Server-side fetches reach blocked and internal hosts via unvalidated HTTP redirect targets CVE-2026-88001Medium5.0fixed in 0.11.1 | Medium5.0 | 0.11.1 |
| Sep 9 | Open WebUI: Any authenticated user can hang the server via a cyclic chat message history CVE-2026-88002Medium6.5fixed in 0.11.1 | Medium6.5 | 0.11.1 |
| Sep 10 | Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange CVE-2026-88005Medium6.5fixed in 0.9.0 | Medium6.5 | 0.9.0 |
| Sep 10 | Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch CVE-2026-87999High7.1fixed in 0.11.1 | High7.1 | 0.11.1 |
| Sep 10 | Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion CVE-2026-87998High7.1fixed in 0.11.1 | High7.1 | 0.11.1 |