OpenWebUI Automation DoS via RRULE Calendar Parsing DoS

Vulnerability Overview Title: Instance-wide stall via recurrence rules with no possible occurrence Description: A recurring rule with a date filter that can never be satisfied (e.g., February 30th) will never occur at any point in time. Calculating its next occurrence causes the calendar library to traverse the entire search range until it reports that there is no next occurrence. This leads to a stall on the shared event loop. An automation creation or update request from one account can indefinitely block the entire deployment for several seconds, and the request can be repeated indefinitely. There is no limit on search time, iteration count, or the pattern of the rule itself. Impact Scope Availability: Causes blocking for every other user on the instance. The blocking duration is proportional to the search time, which the attacker can determine by shaping the rule. For example, a minute-level rule on February 30th takes approximately 4 seconds, and adding a full list to the same request increases the duration to over 30 seconds. The rule is rejected after the search completes, so nothing is stored and nothing is displayed. The cost for automations in the list has already been incurred. Automation limits are checked after validation for each user, so these limits are not reduced. The requests are inexpensive and can be repeated or pipelined, allowing a loop in one account to render the instance unresponsive indefinitely. Other Impacts: There are no confidentiality or integrity impacts, and no data is written. Remediation Fix: Fixed in commit . All recurrence evaluations now run in a separate worker process with a two-second limit, ensuring the event loop remains idle during rule evaluation. If a rule cannot be settled within this limit, it is rejected upon write, and the scheduler skips it. A full upgrade resolves this issue without any configuration changes. Root Cause Affected Components: Recurrence rule validator ( and in ), accessed via and in . Affected Versions: All builds shipped with automation enabled, from version 0.9.0 up to the fix. Validator Issue: The validator checks whether a rule has future occurrences by asking the calendar library for the next future occurrence, treating an empty answer as invalid. For rules that can never match, the library only returns an empty answer after exhausting the entire search space. Both routes are asynchronous handlers that call the validator directly; therefore, the search runs on the event loop, blocking other requests for the duration of the search. An earlier fix that anchored sub-daily rules to the year 2020 was ineffective because the calendar shift changed the search start point, causing rules with no occurrences to be traversed to the end of the representable range. Proof of Concept (POC) Single Next Occurrence Calculation On the released code path, a single call measured on 0.11.0 with the sub-daily fix applied: Combined Variants An hourly frequency variant combining a full and list did not return within 10 minutes. HTTP Request Example Measurements Measurements were taken at the function level on the released validator, with concurrent tasks recording how long they were blocked on the same event loop. On versions 0.9.0, 0.10.2, and 0.11.3, a minute-level rule on February 30th blocked the event loop for 3.6 to 4.0 seconds per call. On version 0.11.4, the same rule and the full variant were rejected after two seconds, and the event loop was never blocked beyond its normal scheduling interval. Both automation routes call the validator directly within their async loops; therefore, a single request blocks the entire instance for its duration.

Goal Reached Thanks to every supporter — we hit 100%!

OpenWebUI Automation DoS via RRULE Calendar Parsing DoS

More from this source