CVE-2026-87012: Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value

Calendar events carry a free-form meta object that is stored as submitted. The scheduler reads each event's alert offset (meta.alert_minutes) from that object in a single pass covering every user's upcoming events. It compares the value numerically without checking its type, and the loop has no per-event error handling.

A user stores an event starting within the next hour, with the alert offset as the text "5". On each poll the comparison raises a type error and the whole pass aborts before it emits anything. No user gets alerts, and no event is marked as alerted. The same events are selected again on the next poll, so the outage lasts as long as the event stays in the one-hour lookahead window. The attacker can sustain it by storing a new event.

The preconditions are light. The calendar must be enabled (default on), and the attacker needs the calendar feature permission, which all users hold by default. An invited account is enough. No admin rights, shared calendar or recurrence rule are needed.

The damage is limited. Chat, timers, automations and the HTTP API keep working, and there is no crash, code execution or data access. Alerts resume once the event leaves the window or is deleted.

Affected: open-webui from 0.9.0, where the calendar feature was introduced, up to but not including 0.11.1. Instances with the calendar disabled (ENABLE_CALENDAR), or with the calendar feature permission removed from regular users (USER_PERMISSIONS_FEATURES_CALENDAR), are not affected. Check the version:

pip show open-webui

For Docker installs, check the image tag or the version in the Open WebUI About page.

Upgrade to 0.11.1:

pip install --upgrade open-webui==0.11.1

The fix is in pull request 28790. The scheduler now treats a non-numeric alert value as unset and uses the default alert offset, and numeric values behave as before. No configuration change is needed, and events that already hold a bad value go back to default timing. The advisory names no other workaround beyond disabling the calendar or removing the calendar feature permission from regular users.

Look in the server log for a repeated type error raised from the calendar alert pass on every scheduler poll. Check whether users stopped receiving calendar reminders at the same time. Open upcoming events and look for a meta alert value stored as text, such as "5" instead of 5. Deleting that event restores alerting on the next poll, which also confirms the cause.

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 poll and alerting resumed.

Credits

Binbin Xu​ of Tencent YUNDING LAB CodeBuddy Security.