CVE-2026-88000: Denial of Service via Infinite Loop in Open WebUI Chat History Deletion

Open WebUI is an extensible, user-friendly, self-hosted interface for managing artificial intelligence workloads and interacting with Large Language Models. To support deep branching conversations, the application structures conversation logs as hierarchical tree networks. Each message node links dynamically to its predecessor and successor nodes, storing child pointers in an internal configuration dictionary.

This backend architecture exposes an attack surface within its chat management API endpoints. Specifically, the message deletion pipeline retrieves and reorganizes child message links when a node is removed. A standard authenticated user can access these interfaces to update, modify, or remove messages from their own personal chat logs.

Because the backend fails to validate structural integrity during JSON document ingestion, users can save chat records that violate directed acyclic graph guidelines. If an attacker introduces cyclic child-parent relationships into their chat history, the deletion logic breaks down. When a deletion is requested, the system enters an infinite loop, starving the runtime environment of CPU resources.

The underlying flaw resides in the recursive traversal logic inside backend/open_webui/models/chats.py. When a user deletes a message, the server attempts to recalculate the chat state. It seeks to resolve the new terminal leaf node (currentId) by stepping down through the list of child references.

The application implements this search via a standard while loop that resolves the last element of the child identifier list. If a cycle exists, such as Message 1 declaring Message 2 as its child, and Message 2 declaring Message 1 as its child, the loop becomes unbounded. The traversal shifts back and forth between these nodes without ever encountering a terminal state.

This behavior has severe consequences because of Python's execution architecture. Open WebUI operates on a single-threaded asynchronous runtime powered by asyncio. A synchronous, CPU-bound infinite loop executes continuously on the main thread without yielding control to other scheduled tasks. Consequently, the entire web server locks up, denying service to all concurrent users on the platform.

The flaw is situated inside the delete_message_from_history() helper function. This function parses the raw chat dictionary and updates pointers. Reviewing the vulnerable implementation reveals a standard unbounded iteration strategy:

def delete_message_from_history(history: dict, message_id: str) -> set[str]:
    # ...
    # Retrieve child messages starting from the target location
    child_ids = (
        messages.get(current_id, {}).get('childrenIds', [])
        if current_id is None
        else messages.get(current_id, {}).get('childrenIds', [])
    )
    
    # Vulnerable loop: Traverses down without tracking visited nodes
    while child_ids:
        current_id = child_ids[-1]
        child_ids = messages.get(current_id, {}).get('childrenIds', [])
        
    history['currentId'] = current_id if current_id in messages else None
    return deleted_ids

The patched version addresses the issue by implementing a cycle-detection tracker. A Python set is initialized to track every node identifier that has already been visited during the execution scope. If the next resolved child ID is identified within this set, the execution breaks the iteration immediately:

def delete_message_from_history(history: dict, message_id: str) -> set[str]:
    # ...
    child_ids = (
        messages.get(current_id, {}).get('childrenIds', [])
        if current_id is None
        else messages.get(current_id, {}).get('childrenIds', [])
    )
    
    # Patched loop: Introduces visited tracking to detect cycles
    visited_ids = set()
    while child_ids and child_ids[-1] not in visited_ids:
        current_id = child_ids[-1]
        visited_ids.add(current_id)
        child_ids = messages.get(current_id, {}).get('childrenIds', [])
        
    history['currentId'] = current_id if current_id in messages else None
    return deleted_ids

Although the local fix stops the execution thread from hanging, it represents a reactive mitigation. The backend database layer still does not validate structural constraints during direct write operations. Therefore, other components that traverse the chat log trees using distinct search functions might also be vulnerable to cycle exploitation.

Exploiting this vulnerability does not require administrative privileges. Any registered user can trigger the vulnerability by submitting standard HTTP API commands to the server. The attacker first crafts a custom JSON payload representing a cyclic graph structure.

The attacker uploads the malformed chat data structure using a POST request to /api/v1/chats/new. Once the chat object is created, the database updates to store the cyclic relationships. The attacker then targets the deletion route to trigger the loop:

DELETE /api/v1/chats/{id}/messages/msg_1

Upon receiving this request, the backend executes the deletion helper. The loop runs indefinitely, consuming 100% of the assigned CPU core resources. Because the async scheduler cannot execute other tasks, all concurrent client requests fail to resolve.

The primary impact of this vulnerability is total denial of service. Because the application uses a single process worker pool by default in many self-hosted environments, a single request can render the entire system offline. This impacts all registered users on the system, regardless of their role.

The vulnerability does not allow remote code execution, database compromise, or unauthorized reading of other users' confidential histories. Therefore, the Confidentiality and Integrity metrics remain at None. However, because the attack is trivial to execute and requires zero user interaction from other victims, the Availability impact is High.

In environments where Open WebUI is exposed to public registration or shared across corporate networks, this flaw allows low-privilege actors to disrupt operational workflows. Recovery requires administrative shell access to terminate the container or server process manually.

The primary solution is to upgrade Open WebUI to version 0.11.1 or higher. This release integrates cycle-detection logic into the deletion backend. Self-hosted instances running on Docker can pull the latest image to apply the updates:

docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui-container
docker rm open-webui-container
docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

If upgrading is not immediately possible, administrators can mitigate the risk by disabling public registration to limit exposure to trusted individuals. Additionally, configuring external reverse-proxy rate limiting on the /api/v1/chats/*/messages endpoint helps block automated exploitation attempts.

Automated tools can monitor server health to identify exploitation. Administrators should configure resource-monitoring rules to alert on sustained high CPU consumption accompanied by unhandled API request timeouts.