Open WebUI: Instance-wide stall via automation recurrence rules that force multi-second parsing
GHSA-73cq-mcgh-379c · CVE-2026-70489 · PYSEC-2026-3644 · 갱신 2026. 8. 19.
영향 받는 패키지
| 생태계 | 패키지 | 수정 버전 |
|---|---|---|
| PyPI | open-webui | 0.11.0 |
GHSA-73cq-mcgh-379c · CVE-2026-70489 · PYSEC-2026-3644 · 갱신 2026. 8. 19.
| 생태계 | 패키지 | 수정 버전 |
|---|---|---|
| PyPI | open-webui | 0.11.0 |
Affected component: backend/open_webui/utils/automations.py, _parse_rule, reached from the automation create, update and toggle handlers in backend/open_webui/routers/automations.py and from the scheduler's claim path in backend/open_webui/models/automations.py. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped.
The fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that "every 5 minutes" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread.
Measured cost of a single next-run computation against the shipped 0.10.2 parser:
| rule | cost |
|---|---|
RRULE:FREQ=MINUTELY | 18,880 ms |
RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9 | 64,236 ms |
DTSTART:20000101T000000 + RRULE:FREQ=MINUTELY | 26,237 ms |
RRULE:FREQ=HOURLY | 339 ms |
Measured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance.
Reported by @Classic298.