Description

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.10.0 until 0.11.1, POST /api/chat/completions and POST /api/v1/chat/completions in backend/open_webui/main.py copied a client-supplied folder_id into a new chat without applying the folder write-access check used by the dedicated chat routes. An authenticated user who knew a shared folder identifier could inject an attacker-controlled chat into a folder where the user had read-only or no write access, causing the entry to appear to authorized folder readers. This issue is fixed in version 0.11.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-09T22:18:48.267Z",
  "pubdate": "2026-09-09T22:18:48.267Z",
  "executiveSummary": "Open WebUI versions 0.10.0 through 0.11.1 are susceptible to an improper access control vulnerability within the chat completion API endpoints.\nThe vulnerability allows an authenticated attacker to perform unauthorized write operations by injecting chat sessions into arbitrary folders, including those for which the user holds read-only or no access permissions.\nThis flaw stems from a lack of server-side validation for folder write-access during the chat creation process in backend/open_webui/main.py.\nBy leveraging a known shared folder identifier, an attacker can manipulate the chat hierarchy, leading to unauthorized content injection.\nThis vulnerability poses significant risks regarding data integrity and unauthorized information disclosure within the platform's multi-user collaborative environment.\nExploitation requires the attacker to be authenticated to the platform and possess knowledge of a target folder identifier.\nThe primary impact is the unauthorized placement of chat entries, which will subsequently appear to legitimate users or administrators authorized to access the targeted folders, potentially leading to social engineering or the degradation of platform trust.",
  "technicalDetails": "The vulnerability is located within the backend/open_webui/main.py component of Open WebUI, specifically affecting the POST /api/chat/completions and POST /api/v1/chat/completions endpoints.\nThe root cause is a failure to implement a robust access control mechanism during the chat object instantiation process. While dedicated chat management routes within the application correctly enforce folder write-access checks, the completion endpoints fail to replicate this authorization logic when processing the client-supplied folder_id parameter.\nExploitation flow: First, an authenticated attacker identifies a valid folder_id associated with a target directory that they should not have write access to. Second, the attacker crafts a malicious HTTP POST request targeting the vulnerable completions endpoints. Within the payload, the attacker includes the identified folder_id in the request body.\nBecause the server-side code blindly trusts the provided folder_id without validating the current user's authorization level for that specific resource, the backend application proceeds to instantiate the chat object and assign it to the target directory.\nConsequently, the attacker-controlled chat entry is persisted in the database under the requested folder path. The impact is significant: the injected chat session becomes visible to any authorized user or administrator who views the contents of the compromised folder. This creates a vector for manipulating the perceived history of shared workspaces or injecting malicious/misleading prompts that might be consumed by other users or automated agents monitoring those folders.\nThe vulnerability exists in all Open WebUI versions from 0.10.0 up to and including 0.11.1. The flaw is specifically tied to the discrepancy in security enforcement between standard chat creation routes and the completions API. By bypassing the intended privilege escalation protections, the system fails to maintain the integrity of user-defined data structures and folder ownership boundaries. Post-exploitation allows the attacker to maintain a persistent presence within restricted areas of the platform, facilitating further unauthorized data dissemination."
}