Summary
Two regexes in backend/open_webui/utils/middleware.py that parse <$skillId|label> skill-mention tags backtrack in O(n²) on input that contains <$ followed by a long run with no closing >. Both run synchronously, on the asyncio event loop, on every chat completion with no feature gate. Because the default deployment is a single uvicorn worker, one such input pins a CPU core inside re and freezes the entire instance for all users until the worker is killed. Any authenticated user can trigger it with one chat message; it also fires accidentally on benign retrieved content (a RAG chunk or tool output) containing the pattern.
Affected versions
>= 0.9.2, < 0.10.0. Fixed in v0.10.0 (there is no 0.9.7 release).
SKILL_MENTION_RE (the extract pattern) has been O(n²) since v0.9.2; exploitable on 0.9.2–0.9.5 with a large input (hundreds of KB).- v0.9.6 added a second, far more aggressive O(n²) in the strip pattern (introduced by the "keep label as readable text" change), so on 0.9.6 a small input is enough to hang the instance.
Both are fixed by the same patch.
Affected component
backend/open_webui/utils/middleware.py (line numbers as of v0.9.6):
# line 2223 — used by extract_skill_ids_from_messages(), called unconditionally (~line 2625)
SKILL_MENTION_RE = re.compile(r'<\$([^|>]+)\|?[^>]*>')
# line 2247 — used by strip_skill_mentions(), called unconditionally (line 2662)
strip_re = re.compile(r'<\$[^|>]+\|?([^>]*)>')
extract_skill_ids_from_messages() runs before the if all_skill_ids: block (that guard gates only skill injection, not the regex), and strip_skill_mentions() runs with no guard at all. Neither requires a skill to exist or any setting to be enabled. Both functions are plain synchronous calls inside the async process_chat_payload coroutine, so they block the event loop; with the default UVICORN_WORKERS=1 (backend/start.sh) the whole instance stalls.
Root cause
[^|>] is a subset of [^>], so the quantifier pair [^|>]+ \|? [^>]* is ambiguous: on input that never closes with >, [^|>]+ greedily consumes the tail, > fails, and the engine backtracks through every split point between [^|>]+ and [^>]* — O(n) positions each doing O(n) work. Polynomial, not exponential, but more than enough to hang a single worker on a ~100 KB input.
Proof of concept
Standalone (no Open WebUI required):
import re, time
EXTRACT = re.compile(r'<\$([^|>]+)\|?[^>]*>')
STRIP = re.compile(r'<\$[^|>]+\|?([^>]*)>')
for n in (8_000, 16_000, 32_000, 64_000):
s = '<$' + ('a' * n)
for name, rx in (('extract', EXTRACT), ('strip', STRIP)):
t = time.perf_counter(); rx.search(s)
print(f'n={n:>6} {name:>7} = {(time.perf_counter()-t)*1000:8.1f} ms')Time quadruples per doubling of n (textbook O(n²)); the strip pattern runs for ~6 seconds on a 64k blob and for minutes on a ~96 KB one.
End-to-end against a live instance (default config):
docker run ghcr.io/open-webui/open-webui:v0.9.6 on defaults.- Log in as any user (no admin or skill setup).
- Send a chat message containing
<$ followed by 50k+ characters with no >.
- One CPU core pegs in
re; UI and API stop responding for every user until the worker is killed.
Patch
Rewrite the optional |label as a non-capturing optional group so the two quantifiers no longer overlap. Both patterns become linear; captures and substituted output are unchanged on well-formed <$id|label>, <$id|>, and bare <$id> mentions.
SKILL_MENTION_RE = re.compile(r'<\$([^|>]+)(?:\|[^>]*)?>')
strip_re = re.compile(r'<\$[^|>]+(?:\|([^>]*))?>')
After the patch the same hostile input returns in under 1 ms. Shipped in v0.10.0.
Credit
Reported by @Vlad-WKG, including a correct root-cause analysis and patch.
References
Vlad-WKG Reporter
Classic298 Remediation developer
Summary
Two regexes in
backend/open_webui/utils/middleware.pythat parse<$skillId|label>skill-mention tags backtrack in O(n²) on input that contains<$followed by a long run with no closing>. Both run synchronously, on the asyncio event loop, on every chat completion with no feature gate. Because the default deployment is a single uvicorn worker, one such input pins a CPU core insidereand freezes the entire instance for all users until the worker is killed. Any authenticated user can trigger it with one chat message; it also fires accidentally on benign retrieved content (a RAG chunk or tool output) containing the pattern.Affected versions
>= 0.9.2, < 0.10.0. Fixed in v0.10.0 (there is no 0.9.7 release).SKILL_MENTION_RE(the extract pattern) has been O(n²) since v0.9.2; exploitable on 0.9.2–0.9.5 with a large input (hundreds of KB).Both are fixed by the same patch.
Affected component
backend/open_webui/utils/middleware.py(line numbers as of v0.9.6):extract_skill_ids_from_messages()runs before theif all_skill_ids:block (that guard gates only skill injection, not the regex), andstrip_skill_mentions()runs with no guard at all. Neither requires a skill to exist or any setting to be enabled. Both functions are plain synchronous calls inside the asyncprocess_chat_payloadcoroutine, so they block the event loop; with the defaultUVICORN_WORKERS=1(backend/start.sh) the whole instance stalls.Root cause
[^|>]is a subset of[^>], so the quantifier pair[^|>]+ \|? [^>]*is ambiguous: on input that never closes with>,[^|>]+greedily consumes the tail,>fails, and the engine backtracks through every split point between[^|>]+and[^>]*— O(n) positions each doing O(n) work. Polynomial, not exponential, but more than enough to hang a single worker on a ~100 KB input.Proof of concept
Standalone (no Open WebUI required):
Time quadruples per doubling of
n(textbook O(n²)); the strip pattern runs for ~6 seconds on a 64k blob and for minutes on a ~96 KB one.End-to-end against a live instance (default config):
docker run ghcr.io/open-webui/open-webui:v0.9.6on defaults.<$followed by 50k+ characters with no>.re; UI and API stop responding for every user until the worker is killed.Patch
Rewrite the optional
|labelas a non-capturing optional group so the two quantifiers no longer overlap. Both patterns become linear; captures and substituted output are unchanged on well-formed<$id|label>,<$id|>, and bare<$id>mentions.After the patch the same hostile input returns in under 1 ms. Shipped in v0.10.0.
Credit
Reported by @Vlad-WKG, including a correct root-cause analysis and patch.
References