---
id: "CVE-2026-109297"
page: "https://infrastack.ai/live/CVE-2026-109297"
kind: "vulnerability"
aliases: ["CVE-2026-109297", "GHSA-whgc-vpjx-m3qh"]
title: "Instance-wide stall via automation recurrence rules that evade sub-daily frequency detection"
severity: "high"
cvss: 7.1
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": ">= 0.11.0, < 0.11.4", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "cwe-400", "cwe-436", "open-webui", "python", "self-hosted"]
not_affected_if: ["admin-only-automations", "default-config"]
published_at: "2026-09-27T19:53:56+00:00"
first_seen_at: "2026-11-09T22:53:27+00:00"
updated_at: "2026-11-09T23:10:12+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-whgc-vpjx-m3qh", "first_seen_at": "2026-11-09T22:53:27+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109297", "first_seen_at": "2026-11-09T23:10:12+00:00"}]
exploit_sources: []
---

# Instance-wide stall via automation recurrence rules that evade sub-daily frequency detection

Link for people: https://infrastack.ai/live/CVE-2026-109297 (this .md is for agents)

Open WebUI's automation validator misreads certain recurrence-rule spellings as ordinary, so a rule that the calendar library reads as per-second is walked from its start date on the shared event loop. An account allowed to create automations can stall the instance for minutes, and the stored rule repeats the stall on every scheduler poll.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:open-webui affected >= 0.11.0, < 0.11.4 fixed 0.11.4

## How to check

- Check the installed version with `pip show open-webui` and confirm it is at or above `0.11.0` and below `0.11.4`.
- Check whether `USER_PERMISSIONS_FEATURES_AUTOMATIONS` is set to `True` for non-administrator users.
- Check `UVICORN_WORKERS`; a value of `1` means there is no second worker to absorb the stall.

## Fix

- Open WebUI `0.11.4` (pypi open-webui, fixed in 0.11.4; affected range 0.11.0 up to but not including 0.11.4)

## Timeline

- 2026-11-09T22:53:27+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-whgc-vpjx-m3qh
- 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109297

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-whgc-vpjx-m3qh
- [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-0.11.0-before-0.11.4-denial-of-service-via-automation-recurrence-rules

## From the sources

# Instance-wide stall via automation recurrence rules that evade sub-daily frequency detection

## Summary
Any account permitted to create automations can submit a recurrence rule that Open WebUI classifies as harmless while the underlying calendar library reads it as a per-second schedule. Validating such a rule walks every occurrence between the rule's start date and now, synchronously on the shared event loop, so a single request leaves the deployment unable to answer anyone for minutes. Once stored, the scheduler repeats that work on every poll. The 0.11.0 release added a guard against exactly this cost, but the guard decides what a rule is by re-reading the submitted text, and several spellings the calendar library accepts never reach it.

## Preconditions
An account permitted to create or update automations. `USER_PERMISSIONS_FEATURES_AUTOMATIONS` defaults to `False`, so out of the box only an administrator qualifies; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the shipped feature usable. `UVICORN_WORKERS` defaults to `1`, so there is no second worker to absorb the stall. Nothing else is required: no knowledge of other users, ids or tokens, and no unusual syntax. Deployments that have not granted the automations permission to non-administrators are reachable only by administrators.

## Impact
Availability, against every other user of the instance and against the operator. Measured on a real instance running 0.11.0, one create request cost 191.59 seconds of blocked event loop, during which 37 of 48 health checks issued by a second client timed out. The request is cheap to issue and can be repeated or pipelined, and because the rule is accepted and stored, the scheduler re-enters the same parsing on each poll, so the instance does not recover on its own. There is no confidentiality or integrity impact, and no data is disclosed or modified.

## Fix
Fixed in https://github.com/open-webui/open-webui/pull/29262 and the accompanying recurrence refactor, both released in 0.11.4. The parser takes the frequency, interval and rule count from the rule the calendar library actually built and splits the rule text on any whitespace the same way the library does, so every accepted spelling is classified and bounded alike. Every schedule evaluation also now runs outside the event loop under a two second budget, so no rule can stall the instance. Upgrading fully resolves the issue; no configuration change is required.

## Root cause
Affected component: the recurrence-rule parser and validator in `backend/open_webui/utils/automations.py`. Reached from the automation create, update and toggle handlers in `backend/open_webui/routers/automations.py`, from the built-in automation tools, and from the scheduler's claim path in `backend/open_webui/models/automations.py`. Affected setup: 0.11.0 is affected by every spelling below; 0.11.1 to 0.11.3 are affected by the whitespace-folded spellings only.

The 0.11.0 fix bounds the work by recognising sub-second, per-minute and hourly rules and re-anchoring them near the present. It recognises them by parsing the submitted rule text a second time, by hand, and comparing the result against a fixed set of names. That second parse is stricter than the calendar library's: it matches the frequency name case-sensitively where the library is case-insensitive, it looks for rules on their own lines where the library splits on any whitespace, and it requires a rule keyword prefix the library treats as optional. A rule that any of those disagreements hides is accepted as ordinary and then walked from its stated start date, which is the unbounded behaviour the guard exists to prevent. The guard was present, but it inspected a different reading of the input than the one that was executed.

## Proof of concept
Against a real instance running 0.11.0, as an account permitted to create automations. Nothing was seeded directly; each rule was submitted through the normal create endpoint.

Lower-case frequency value:

```
DTSTART:20000101T000000
RRULE:FREQ=secondly;INTERVAL=1
```

Ordinary upper-case frequency with no rule keyword prefix, which the guard misses just as completely:

```
DTSTART:20000101T000000
FREQ=SECONDLY;INTERVAL=1
```

Folding the same two lines onto one line separated by a space, or by a tab, has the same effect, as does joining two rule lines by whitespace, which additionally slips past the check that only one recurrence rule was submitted.

Submitting the first rule returned HTTP 200 after 191.59 seconds. A second client polling an unauthenticated health endpoint throughout recorded 37 timeouts across 48 attempts. Submitting the second rule returned HTTP 200 after 154.72 seconds. For comparison, the same rules spelled in the form the guard recognises are validated in under a millisecond.

## Credits
@baeseungwon1010 reported the case-varied frequency value, and demonstrated that a rule differing from a benign one only in letter case reaches the unbounded path.

@Classic298 identified the remaining spellings that reach the same path with an ordinary upper-case frequency: a rule submitted without the recurrence keyword prefix, the same rule folded onto a single line by whitespace, and two recurrence rules joined by whitespace, which also defeats the single-rule check.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_