Summary
Open WebUI: Any authenticated user can hang the server via message deletion in a cyclic chat tree
Chat histories are stored as an unvalidated JSON object. After a message is deleted, the code that picks the chat's new current message walked down the childrenIds links without recording where it had already been. Any account with the default user role could store a chat whose messages list each other as children, then delete a message from it, and the walk would run forever. That walk runs on the server's request loop, so it blocks every other user's requests until the process is killed.
Preconditions
One account with the default user role. No administrator rights, no additional permissions, no configuration change and no non-default setting: creating and deleting chats is available to every user out of the box. The attack runs entirely against the attacker's own chat, so no knowledge of any other user's data is needed. Versions before 0.10.0 are unaffected because neither the message-deletion endpoint nor the affected code existed.
Root cause
Affected component: the chat-history message deletion helper in backend/open_webui/models/chats.py, reached from DELETE /api/v1/chats/{id}/messages/{message_id}. Affected setup: all builds from 0.10.0 up to and including 0.11.0.
Resolving the chat's new current message after a deletion means descending to the deepest remaining child, and that descent had no notion of where it had already been, so two messages naming each other as children sent it back and forth indefinitely. The write path does not validate the structure of a chat's history, and the child-link rebuild that runs on other write paths does not apply when a chat is created, so a history whose childrenIds form a cycle was persisted exactly as submitted.
Proof of concept
As a default-role user on a running instance, store one chat of roughly 300 bytes whose messages reference each other as children:
{"chat":{"title":"poc","history":{"currentId":"C","messages":{
"A":{"id":"A","parentId":null,"role":"user","content":"a","childrenIds":["B","C"],"timestamp":1},
"B":{"id":"B","parentId":"A","role":"assistant","content":"b","childrenIds":["A"],"timestamp":2},
"C":{"id":"C","parentId":"A","role":"user","content":"c","childrenIds":[],"timestamp":3}}}}}
POST /api/v1/chats/new stores it verbatim, with the child links unchanged. A single DELETE /api/v1/chats/{id}/messages/C as the same user then never returns:
unauthenticated GET /health -> HTTP 000 after 10.007s
DELETE -> HTTP 000 after 20.007s
Sampled during the hang, the worker had consumed 42.9 seconds of CPU on one fully occupied core with flat resident memory, and unauthenticated GET /health timed out for as long as the process lived, including after the attacker's connection closed.
On 0.11.1 the same payload returns HTTP 200 in 0.011s, /health stays available throughout, and deleting a middle message from a well-formed four-message chain still resolves the current message correctly.
Credits
@Classic298, who found the unguarded descent through the chat's child links, demonstrated the resulting server-wide outage end to end against a live instance, and supplied the fix.
Impact
The walk is synchronous and runs on the asyncio event loop, so while it spins, every request from every user is blocked, including unauthenticated /health and administrator endpoints. External health checks and orchestrator liveness probes fail alongside the UI. This is a pure CPU pin with no list growth, so a worker consumes one full core with flat memory and has to be killed rather than being reclaimed by an out-of-memory kill. The work is not cancelled when the client disconnects, so a single fire-and-forget request is enough and the attacker can disconnect immediately. The malformed chat stays in the database, so the condition re-arms on the next deletion attempt against that chat. No data is disclosed, altered or deleted.
CVE-2026-88000 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.11.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 0.11.1 by https://github.com/open-webui/open-webui/commit/b933292d63d12be3fd1416fe55519ddc7aa336bc. The walk now records the ids it has already passed through, so it terminates after at most one step per stored message whatever the message contents are. Upgrading fully resolves the issue, including for chats stored while the deployment was on an affected version, which become harmless once the walk terminates.
Frequently Asked Questions
- What is CVE-2026-88000? CVE-2026-88000 is a medium-severity security vulnerability in open-webui (pip), affecting versions >= 0.10.0, < 0.11.1. It is fixed in 0.11.1.
- How severe is CVE-2026-88000? CVE-2026-88000 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of open-webui are affected by CVE-2026-88000? open-webui (pip) versions >= 0.10.0, < 0.11.1 is affected.
- Is there a fix for CVE-2026-88000? Yes. CVE-2026-88000 is fixed in 0.11.1. Upgrade to this version or later.
- Is CVE-2026-88000 exploitable, and should I be worried? Whether CVE-2026-88000 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-88000 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-88000? Upgrade
open-webuito 0.11.1 or later.