Affected: open-webui

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.10.0 until 0.11.1, DELETE /api/v1/chats/{id}/messages/{message_id} used the chat-history deletion helper in backend/open_webui/models/chats.py to follow childrenIds without recording visited message identifiers. An authenticated user could store a cyclic chat tree and delete a message, causing a synchronous infinite loop on the server request loop that blocked every user's requests until the process was killed. This issue is fixed in version 0.11.1.

Affected: PyPI: open-webui

## Summary 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.

## 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…