CVE-2026-87012

# 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 contin