PYSEC-2026-3596
Vulnerability from pysec - Published: 2026-08-04 11:34 - Updated: 2026-08-04 13:36Summary
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):
1. docker run ghcr.io/open-webui/open-webui:v0.9.6 on defaults.
2. Log in as any user (no admin or skill setup).
3. Send a chat message containing <$ followed by 50k+ characters with no >.
4. 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.
| Name | purl | open-webui | pkg:pypi/open-webui |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui",
"purl": "pkg:pypi/open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.2"
},
{
"fixed": "0.10.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.9.2",
"0.9.3",
"0.9.4",
"0.9.5",
"0.9.6"
]
}
],
"aliases": [
"CVE-2026-59220",
"GHSA-ffpj-xv5c-p3gw"
],
"details": "## Summary\nTwo regexes in `backend/open_webui/utils/middleware.py` that parse `\u003c$skillId|label\u003e` skill-mention tags backtrack in O(n\u00b2) on input that contains `\u003c$` followed by a long run with no closing `\u003e`. 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.\n\n## Affected versions\n`\u003e= 0.9.2, \u003c 0.10.0`. Fixed in **v0.10.0** (there is no 0.9.7 release).\n- `SKILL_MENTION_RE` (the extract pattern) has been O(n\u00b2) since **v0.9.2**; exploitable on 0.9.2\u20130.9.5 with a large input (hundreds of KB).\n- **v0.9.6** added a second, far more aggressive O(n\u00b2) 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.\n\nBoth are fixed by the same patch.\n\n## Affected component\n`backend/open_webui/utils/middleware.py` (line numbers as of v0.9.6):\n\n```python\n# line 2223 \u2014 used by extract_skill_ids_from_messages(), called unconditionally (~line 2625)\nSKILL_MENTION_RE = re.compile(r\u0027\u003c\\$([^|\u003e]+)\\|?[^\u003e]*\u003e\u0027)\n\n# line 2247 \u2014 used by strip_skill_mentions(), called unconditionally (line 2662)\nstrip_re = re.compile(r\u0027\u003c\\$[^|\u003e]+\\|?([^\u003e]*)\u003e\u0027)\n```\n\n`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.\n\n## Root cause\n`[^|\u003e]` is a subset of `[^\u003e]`, so the quantifier pair `[^|\u003e]+ \\|? [^\u003e]*` is ambiguous: on input that never closes with `\u003e`, `[^|\u003e]+` greedily consumes the tail, `\u003e` fails, and the engine backtracks through every split point between `[^|\u003e]+` and `[^\u003e]*` \u2014 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.\n\n## Proof of concept\nStandalone (no Open WebUI required):\n\n```python\nimport re, time\nEXTRACT = re.compile(r\u0027\u003c\\$([^|\u003e]+)\\|?[^\u003e]*\u003e\u0027)\nSTRIP = re.compile(r\u0027\u003c\\$[^|\u003e]+\\|?([^\u003e]*)\u003e\u0027)\nfor n in (8_000, 16_000, 32_000, 64_000):\n s = \u0027\u003c$\u0027 + (\u0027a\u0027 * n)\n for name, rx in ((\u0027extract\u0027, EXTRACT), (\u0027strip\u0027, STRIP)):\n t = time.perf_counter(); rx.search(s)\n print(f\u0027n={n:\u003e6} {name:\u003e7} = {(time.perf_counter()-t)*1000:8.1f} ms\u0027)\n```\n\nTime quadruples per doubling of `n` (textbook O(n\u00b2)); the strip pattern runs for ~6 seconds on a 64k blob and for minutes on a ~96 KB one.\n\nEnd-to-end against a live instance (default config):\n1. `docker run ghcr.io/open-webui/open-webui:v0.9.6` on defaults.\n2. Log in as any user (no admin or skill setup).\n3. Send a chat message containing `\u003c$` followed by 50k+ characters with no `\u003e`.\n4. One CPU core pegs in `re`; UI and API stop responding for every user until the worker is killed.\n\n## Patch\nRewrite 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 `\u003c$id|label\u003e`, `\u003c$id|\u003e`, and bare `\u003c$id\u003e` mentions.\n\n```python\nSKILL_MENTION_RE = re.compile(r\u0027\u003c\\$([^|\u003e]+)(?:\\|[^\u003e]*)?\u003e\u0027)\nstrip_re = re.compile(r\u0027\u003c\\$[^|\u003e]+(?:\\|([^\u003e]*))?\u003e\u0027)\n```\n\nAfter the patch the same hostile input returns in under 1 ms. Shipped in v0.10.0.\n\n## Credit\nReported by @Vlad-WKG, including a correct root-cause analysis and patch.",
"id": "PYSEC-2026-3596",
"modified": "2026-08-04T13:36:26.123037Z",
"published": "2026-08-04T11:34:42.517179Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-ffpj-xv5c-p3gw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59220"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/61a26722155ec6ee1b629cf8dfcf975098c18331"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
},
{
"type": "PACKAGE",
"url": "https://pypi.org/project/open-webui"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-ffpj-xv5c-p3gw"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: ReDoS in skill-mention regexes causes whole-instance DoS on default config"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.