Summary
Chat histories are stored as an unvalidated JSON object. The walk that reconstructs a chat's message chain detected repeats using each message's own id field while moving through the history by map key, so a message that simply omitted id was never recorded as visited. A history whose messages referenced each other in a parent cycle therefore made the walk run forever. Any account with the default user role could store such a chat and trigger the walk, blocking the server for everyone.
Preconditions
One account with the default user role. No administrator rights, no additional permissions, no configuration change and no non-default setting: creating a chat 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. Instances where every account is trusted are affected in the sense that the fault is reachable, but require a user acting deliberately.
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. The list it appends to grows without bound, so a memory-capped deployment ends in an out-of-memory kill rather than a hang. The work is not cancelled when the client disconnects, so one fire-and-forget request is enough and the attacker can disconnect immediately. The malformed chat stays in the database, so restarting the process does not clear the condition: the next request that walks that chat hangs the new process, and recovery requires deleting the stored chat. No data is disclosed, altered or deleted.
Fix
Fixed in 0.11.1 by open-webui/open-webui@5c79ccc. The walk now records the map key it is currently positioned at instead of the message's self-reported id, 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.
Root cause
Affected component: the message-chain reconstruction helper in backend/open_webui/utils/misc.py, reached from every path that rebuilds a chat's history, including chat completion, per-chat statistics, context compaction, subagents and timers. Affected setup: all builds from 0.5.0 up to and including 0.11.0.
The loop's visited set was keyed on the message body's id field while the loop itself advanced by looking the parent up as a key in the history map, so the two used different notions of identity. That id field is part of the stored chat object and is fully attacker-controlled, and the guard explicitly skipped recording it when absent, which left the exit condition unreachable for any message that omitted it. The write path does not validate the structure of a chat's history, so a history containing id-less messages in a parent cycle was persisted exactly as submitted.
Proof of concept
As a default-role user on a running instance, store one chat of two messages that reference each other as parents, with the id field omitted:
{"chat":{"title":"poc","history":{"currentId":"A","messages":{
"A":{"parentId":"B","role":"user","content":"a","childrenIds":[]},
"B":{"parentId":"A","role":"assistant","content":"b","childrenIds":[]}}}}}POST /api/v1/chats/new stores it verbatim. A single subsequent GET /api/v1/chats/stats/usage as the same user then never returns. Sampled during the hang, the worker consumed one full CPU core and reached 1.86 GB resident within 60 seconds, still growing. Unauthenticated GET /health and administrator API calls both time out for as long as the process lives, and continue to do so after the attacker's connection closes. Restarting the server restores service until the first request that walks the stored chat, which hangs the new process the same way.
On 0.11.1 the same payload returns promptly, /health stays available throughout, and a well-formed chat still resolves its full history.
Credits
@YashvantHange, who reported the missing-id cycle in the message-chain walk, demonstrated the resulting server-wide outage end to end against a live instance, and showed that it survives both attacker disconnect and a process restart.
References
YashvantHange Reporter
Classic298 Remediation developer
Summary
Chat histories are stored as an unvalidated JSON object. The walk that reconstructs a chat's message chain detected repeats using each message's own
idfield while moving through the history by map key, so a message that simply omittedidwas never recorded as visited. A history whose messages referenced each other in a parent cycle therefore made the walk run forever. Any account with the defaultuserrole could store such a chat and trigger the walk, blocking the server for everyone.Preconditions
One account with the default
userrole. No administrator rights, no additional permissions, no configuration change and no non-default setting: creating a chat 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. Instances where every account is trusted are affected in the sense that the fault is reachable, but require a user acting deliberately.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
/healthand administrator endpoints. External health checks and orchestrator liveness probes fail alongside the UI. The list it appends to grows without bound, so a memory-capped deployment ends in an out-of-memory kill rather than a hang. The work is not cancelled when the client disconnects, so one fire-and-forget request is enough and the attacker can disconnect immediately. The malformed chat stays in the database, so restarting the process does not clear the condition: the next request that walks that chat hangs the new process, and recovery requires deleting the stored chat. No data is disclosed, altered or deleted.Fix
Fixed in 0.11.1 by open-webui/open-webui@5c79ccc. The walk now records the map key it is currently positioned at instead of the message's self-reported
id, 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.Root cause
Affected component: the message-chain reconstruction helper in
backend/open_webui/utils/misc.py, reached from every path that rebuilds a chat's history, including chat completion, per-chat statistics, context compaction, subagents and timers. Affected setup: all builds from 0.5.0 up to and including 0.11.0.The loop's visited set was keyed on the message body's
idfield while the loop itself advanced by looking the parent up as a key in the history map, so the two used different notions of identity. Thatidfield is part of the stored chat object and is fully attacker-controlled, and the guard explicitly skipped recording it when absent, which left the exit condition unreachable for any message that omitted it. The write path does not validate the structure of a chat's history, so a history containing id-less messages in a parent cycle was persisted exactly as submitted.Proof of concept
As a default-role user on a running instance, store one chat of two messages that reference each other as parents, with the
idfield omitted:{"chat":{"title":"poc","history":{"currentId":"A","messages":{ "A":{"parentId":"B","role":"user","content":"a","childrenIds":[]}, "B":{"parentId":"A","role":"assistant","content":"b","childrenIds":[]}}}}}POST /api/v1/chats/newstores it verbatim. A single subsequentGET /api/v1/chats/stats/usageas the same user then never returns. Sampled during the hang, the worker consumed one full CPU core and reached 1.86 GB resident within 60 seconds, still growing. UnauthenticatedGET /healthand administrator API calls both time out for as long as the process lives, and continue to do so after the attacker's connection closes. Restarting the server restores service until the first request that walks the stored chat, which hangs the new process the same way.On 0.11.1 the same payload returns promptly,
/healthstays available throughout, and a well-formed chat still resolves its full history.Credits
@YashvantHange, who reported the missing-
idcycle in the message-chain walk, demonstrated the resulting server-wide outage end to end against a live instance, and showed that it survives both attacker disconnect and a process restart.References