Stored XSS to Account Takeover via Model Profile Images in Open WebUI Affected: Open WebUI <= 0.9.5 Bypass of: GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc TL;DR Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validate_profile_image_url field validator, and the model image serving endpoint has no MIME allowlist or nosniff header. Any authenticated user …
Open WebUI renders Mermaid blocks from Markdown files in the file preview panel and inserts the generated SVG into the DOM using innerHTML. Because Mermaid is configured with securityLevel: 'loose', attacker-controlled Mermaid content can be rendered unsafely in this flow. A working payload was validated through the Markdown preview path, resulting in JavaScript execution in the victim’s browser under the application origin. This is a confirmed stored XSS vulnerability reachable …
The SafePlaywrightURLLoader implements a validate_url function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL. Since Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata). This allows the application to …
A path traversal vulnerability exists in open-webui's cache file serving endpoint that allows any authenticated user to read files from sibling directories outside the intended cache directory, by exploiting an incomplete startswith containment check that lacks a trailing path separator. The root cause is that serve_cache_file() in open_webui/main.py validates the resolved path with file_path.startswith(os.path.abspath(CACHE_DIR)) — without appending os.sep. This allows any path resolving to a sibling directory whose name begins …
backend/open_webui/utils/oauth.py::_process_picture_url (v0.9.5, lines 1435-1470) calls validate_url(picture_url) on the initial URL only, then invokes aiohttp.ClientSession.get(picture_url, …) without allow_redirects=False. aiohttp's default is allow_redirects=True, max_redirects=10; the function does not pass the project's AIOHTTP_CLIENT_ALLOW_REDIRECTS env constant either. An attacker with a valid OAuth IdP identity can therefore submit a public URL that 302-redirects to an internal address and read the internal response body via the attacker's own profile_image_url field. This is the same redirect-bypass …
This is a bypass of the fix for: GHSA-h36f-rqpx-j5wx CVE-2026-44560 "Unauthorized File and Knowledge Base Content Access via RAG Vector Search" Open WebUI added collection-level ACL checks, but the patch can still be bypassed when Milvus multitenancy mode is enabled. The ACL allows unknown non-KB collection names as legacy/ephemeral collections. In Milvus multitenancy mode, that user-controlled collection name becomes a resource_id and is interpolated into a Milvus expression without escaping. …
The terminal-server reverse proxy in backend/open_webui/routers/terminals.py does not fully confine the user-controlled path segment before forwarding it to an admin-configured terminal server. An authenticated user who has been granted access to a terminal server can craft path values containing encoded ../ traversal sequences that escape the intended path (or policy) scope on that server, reaching unintended endpoints and files on the terminal-server host. Where the terminal server fans requests out …
Open WebUI lets a user who can create, update, or import workspace models store arbitrary meta.knowledge entries on their model without checking whether they own or can read the referenced files. Open WebUI then treats meta.knowledge entries of type file as an authorization source in two places: the built-in view_file tool reads the file's extracted text, and has_access_to_file()'s model branch authorizes the file content and file delete endpoints. A malicious …
Open WebUI v0.9.5 lets an authenticated user attach arbitrary file_id values to their own chat message without checking whether they own or can read those files. If the attacker then shares that chat and grants themselves read access, has_access_to_file() treats the victim file as accessible through the shared chat, and the file endpoints read or delete the victim file.
POST /api/chat/completions accepts an image_url.url value that, when it does NOT start with http://, https://, or data:image/, is interpreted as a file id and resolved against the global file table with no ownership check. An authenticated user can therefore set image_url.url to another user's file id, the server reads that file from disk, base64-encodes it, and injects the data URI into the LLM request. The user then prompts the LLM …
The chat message listener allows non-same-origin input:prompt and action:submit messages, so an external site can set prompt text and trigger submitPrompt() in an authenticated victim session. I validated this with a cross-origin attacker page that auto-posted messages and caused unauthorized POST /api/v1/chats/new and POST /api/chat/completions requests containing attacker-controlled prompts. This enables cross-site forced actions and model/tool execution under victim privileges without consent.
Several direct, index-addressed Ollama proxy routes accept a caller-supplied url_idx path parameter and use it as a raw index into the admin-configured OLLAMA_BASE_URLS list. Access control on these routes validates only whether the user may use the requested model, never which backend the request is routed to. Any authenticated user can append an arbitrary url_idx to force their request onto an Ollama backend they were never authorized to reach, including …
The ydoc:document:join Socket.IO handler checks note ownership only when the document_id starts with note: (colon). However, the YdocManager storage layer normalizes all document IDs by replacing colons with underscores (document_id.replace(":", "")). An attacker can join a document room using note<id> (underscore) instead of note:<id> (colon), bypassing the authorization check entirely while accessing the same underlying Yjs document. The server then returns the full document state, leaking the victim's private note …
Open WebUI's prompt version-history endpoints authorize the prompt_id in the URL but then act on caller-supplied history IDs without verifying that the history row belongs to that prompt (history_entry.prompt_id == prompt.id). Three operations are affected: GET /api/v1/prompts/id/{prompt_id}/history/diff — returns another prompt's history snapshots (read). POST /api/v1/prompts/id/{prompt_id}/update/version — restores another prompt's snapshot into the caller's prompt, exposing its content (read). DELETE /api/v1/prompts/id/{prompt_id}/history/{history_id} — deletes another prompt's history entry (delete). An authenticated …
POST /api/v1/calendars/events/{event_id}/update validates that the caller has write access to the calendar the event currently belongs to, but does not validate the destination calendar_id supplied in the request body. The model layer then persists the new calendar_id unconditionally. A regular user-role account can therefore create an event in their own calendar and immediately move it into any other user's calendar whose ID they know — bypassing the authorization check that …
Open WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin search_knowledge_files tool. When native function calling is enabled and the selected model has no attached knowledge bases, an authenticated user can call search_knowledge_files with an arbitrary knowledge_id. The function then returns file metadata from that knowledge base without checking whether the user has read access. This allows unauthorized enumeration of private or restricted knowledge base files.
Open WebUI v0.6.43 contains a vulnerability in its chat completion API, which allows attackers to bypass tool restrictions, potentially enabling unauthorized actions or access.
GET /api/v1/memories/ef is accessible without authentication and executes request.app.state.EMBEDDING_FUNCTION(…). This allows any unauthenticated caller to trigger embedding generation which can lead to direct cost exposure if a paid provider is used. Code reference: backend/open_webui/routers/memories.py (@router.get("/ef") -> calls request.app.state.EMBEDDING_FUNCTION("hello world")).
When setting model permissions so that a group has read access to it, intending for other users to use it, those users also can read the model's system prompt. However users may consider their system prompt confidential, so we consider this a security issue. Compare https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/ or prompt injections to get popular chatbots on the internet to reveal their prompt.
Any authenticated user can permanently delete files owned by other users via DELETE /api/v1/files/{id} when the target file is referenced in any shared chat. The has_access_to_file() authorization gate unconditionally grants access through its shared-chat branch. It checks neither the requesting user's identity nor the type of operation being performed. File UUIDs (which would otherwise be impractical to guess) are disclosed to any user with read access to a knowledge base …
The POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the is_pinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. All other write endpoints (update, delete, access/update) correctly check for write permission.
A missing permission check in all files related API endpoints allows any authenticated user to list, access and delete every file uploaded by every user to the platform.
The POST /api/v1/evaluations/feedback endpoint in Open WebUI v0.9.2 is vulnerable to mass assignment via FeedbackForm, which uses model_config = ConfigDict(extra='allow'). Due to an insecure dictionary merge order in insert_new_feedback(), an authenticated attacker can inject a user_id field in the request body that overwrites the server-derived value, creating feedback records attributed to any arbitrary user. This corrupts the model evaluation leaderboard (Elo ratings) and enables identity spoofing.
Any authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{task_id} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users' active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments.
The LDAP and OAuth authentication flows use a TOCTOU (Time-of-Check-Time-of-Use) pattern for first-user admin role assignment. The regular signup handler (signup_handler in auths.py, line 663) was explicitly patched to prevent this race with the comment "Insert with default role first to avoid TOCTOU race", but the LDAP and OAuth code paths were never updated with the same fix.
The /api/v1/utils/code/execute endpoint executes arbitrary Python code via Jupyter for any verified user, even when the admin has set ENABLE_CODE_EXECUTION=false. The feature gate is not enforced on the API endpoint — the configuration says "disabled" but code still executes.
Multiple endpoints accept a user-supplied file_id and attach the referenced file to a resource the caller controls (folder knowledge, knowledge-base contents) without verifying that the caller owns or has been granted access to the file. The file's content then becomes reachable through the downstream RAG / file-content paths, allowing any authenticated user to exfiltrate any other user's private file — and on the knowledge-base path, also to overwrite it — …
An internal-only bypass_filter parameter is exposed on the /openai/chat/completions and /ollama/api/chat HTTP endpoints via FastAPI query string binding, allowing any authenticated user to append ?bypass_filter=true and bypass model access control checks to invoke admin-restricted models.
GET /api/v1/retrieval/ returns live RAG pipeline configuration to any unauthenticated HTTP client. No Authorization header, cookie, or API key is required. Every adjacent endpoint on the same router (/embedding, /config) is correctly guarded by get_admin_user making this a targeted omission.
When a user signs in via OAuth, Open WebUI fetches the picture claim URL, infers a MIME type from the URL extension via mimetypes.guess_type, and stores data:<mime>;base64,… as the user's profile image. The OAuth code path does not go through the validate_profile_image_url Pydantic validator that normally restricts profile images to PNG/JPEG/GIF/WebP. A .svg URL in the picture claim lands in the database as data:image/svg+xml;base64,…. The profile image endpoint GET /api/v1/users/{id}/profile/image …
A Server-Side Request Forgery (SSRF) vulnerability exists in _process_picture_url() in backend/open_webui/utils/oauth.py (line ~1338). The function fetches arbitrary URLs from OAuth picture claims without applying validate_url(), allowing an attacker to force the server to make HTTP requests to internal resources and exfiltrate the full response.
_validate_collection_access() (PR #22109) checks the user-memory-* and file-* collection name prefixes but does not check knowledge base collections, which use raw UUIDs as collection names. Any authenticated user who knows a private knowledge base UUID can read its content through the retrieval query endpoints, even though the knowledge API correctly denies that user access. The same gap affects the retrieval write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube), allowing an attacker …
An application-wide Cross-Site Request Forgery (CSRF) vulnerability was found Open-WebUl's image uploading functionality. An attacker can set an image URL to a malicious endpoint, allowing them to perform actions on behalf of a victim user. Any authenticated user can exploit this vulnerability, and any user who views the compromised image (e.g., a profile picture) will unknowingly send a GET request to the attacker-controlled URL. This can lead to cookie theft, …
Blind server side request forgery (SSRF) via the PDF generate function. The finding resulted from a penetration test for a customer. It is suspected that the root cause of the issue lies within the core of Open WebUI, which is why it is being reported as a security issue here. Tested on Open WebUI 0.5.4.
A user can modify another user's model even if its visibility is set to Private. The finding resulted from a penetration test for a customer. It is suspected that the root cause of the issue lies within the core of Open WebUI, which is why it is being reported as a security issue here. Tested on Open WebUI 0.5.4.
The channel webhook create/update flow accepts arbitrary profile_image_url values, including data:image/svg+xml;base64,… payloads. The profile image endpoint then decodes and serves this SVG as image/svg+xml without sanitization, allowing attacker-controlled script handlers (for example onload) to execute when the profile-image URL is opened in the browser.
Open WebUI renders user-uploaded Office files (Excel, DOCX) as HTML using Svelte's {@html} directive without DOMPurify sanitization. While the codebase has DOMPurify available and uses it in 9 out of 23 {@html} locations (39%), three file-preview rendering paths bypass it entirely, allowing Stored XSS when a user uploads a malicious document. This is a classic defense propagation failure: the sanitization primitive exists in the codebase but is not consistently applied …
Through the HTML rendering view, scripts can be injected and executed. The finding resulted from a penetration test for a customer. It is suspected that the root cause of the issue lies within the core of Open WebUI, which is why it is being reported as a security issue here. Tested on Open WebUI 0.5.4.
The audio transcription upload endpoint takes the file extension from the user-supplied filename and saves the file under CACHE_DIR/audio/transcriptions/.. The /cache/{path} route serves these files via FileResponse, which sets Content-Type from the on-disk extension and emits no Content-Disposition. A verified user with the default-on chat.stt permission can upload a polyglot WAV+HTML file named pwn.html and trick any other user into opening the resulting URL — the response comes back as …
The profile_image_url field on the user profile update form accepted arbitrary data: URI values without MIME-type validation. Two distinct attack paths were independently demonstrated by separate reporters: data:text/html;base64,… in a new browser tab (raresvis, 2025-04-17) — when a victim right-clicks a user's profile picture and chooses "Open image in new tab", the browser navigates to the data: URL and executes embedded scripts in the data: origin. Limited to social-engineering / …
Any user X can continue the conversation of any other user Y, as long as the Chat ID of Y is known. User X does not even need to be an admin to do so.
The API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.
An IDOR vulnerability exists in the Channels feature of Open WebUI, allowing any channel member to modify messages sent by other members (including administrators) within the same channel. This vulnerability affects the latest version (v0.8.12) of Open WebUI.
Pin/Unpin is a write operation (modifies the message's is_pinned , pinned_by, pinned_at fields), but in standard channels it only checks read permission, allowing users with read-only access to pin/unpin any message.
The validate_url() function in backend/open_webui/retrieval/web/utils.py only validates the initial URL submitted by the caller. The HTTP clients used downstream (sync requests, async aiohttp, langchain's WebBaseLoader) follow HTTP 3xx redirects by default and do not re-validate the redirect target against the private-IP / metadata-IP block list. Any authenticated user can therefore submit a public URL that 302-redirects to an internal address (e.g. 127.0.0.1, 169.254.169.254, RFC1918) and read the internal response body …
In the open-webui project, a parsing difference between the urlparse and requests libraries led to an SSRF bypass vulnerability.
validate_url() in backend/open_webui/retrieval/web/utils.py calls validators.ipv6(ip, private=True), but the validators library does NOT implement the private keyword for IPv6 — the call raises a ValidationError (which is falsy in a boolean context), so every IPv6 address passes the filter. In addition, IPv4-mapped IPv6 (::ffff:10.0.0.1) bypasses the IPv4 check entirely, and several reserved IPv4 ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.0.0/24, etc.) are not blocked. The vulnerability has existed since the validate_url() function was introduced …
A regular user [non-admin] can view the system prompt of the model which is set by an admin.
There's an IDOR in the channels message management system that allows authenticated users to modify or delete any message within channels they have read access to. The vulnerability exists in the message update and delete endpoints, which implement channel-level authorization but completely lack message ownership validation. While the frontend correctly implements ownership checks (showing edit/delete buttons only for message owners or admins), the backend APIs bypass these protections by only …
Vulnerability Description In standard channels (i.e., channels whose channel.type is neither group nor dm), the endpoint POST /api/v1/channels/{channel_id}/messages/{message_id}/update can be accessed with read permission only. When access_control is set to None, the authorization check has_access(…, type="read") evaluates to True, allowing users who are not the message owner to update messages. As a result, unauthorized modification of other users’ messages is possible. Attack Prerequisites The attacker is an authenticated user (role …
Authorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users' memories.
Due to a CORS misconfiguration and session validation issue, an attacker may be able to perform a 1 click attack against browsers with admin access to openwebui, resulting in remote code execution in the openwebui instance. The openwebui application runs as root in Docker container's default setup, which allows for complete compromise of the container.
** CONFIDENTIAL ** Vulnerability Disclosure Analysis Documentation Vulnerability Details Discoverer: Taylor Pennington of KoreLogic, Inc. Date Submitted: June 11, 2024 Title: Open WebUI Arbitrary File Write, Delete via Path Traversal High-level Summary: Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traversal vulnerability. After the file is written, it is deleted. Affected Vendor: Open WebUI Affected Product(s): Open WebUI (Formerly Ollama …
The ydoc:document:update Socket.IO event handler checks whether the sender is a member of the document's Socket.IO room (line 678) but does not verify that the sender has write permission. Users with read-only access join the document room via ydoc:document:join, which only requires read permission (line 520). Once in the room, the user can emit ydoc:document:update events that modify the in-memory Yjs document state and are broadcast to all other collaborators …
This is a stored cross-site scripting (XSS) vulnerability that allows any authenticated user with model creation permission (workspace.models) to execute arbitrary JavaScript in the browser of any other user (including admins) who views the malicious model in the chat UI.
The /responses endpoint in the OpenAI router accepts any authenticated user and forwards requests directly to upstream LLM providers without enforcing per-model access control. While the primary chat completion endpoint (generate_chat_completion) checks model ownership, group membership, and AccessGrants before allowing a request, the /responses proxy only validates that the user has a valid session via get_verified_user. This allows any authenticated user — regardless of role or group assignment — to …
Four Ollama proxy endpoints accept any model name from the user and forward the request to the Ollama backend without checking whether the user is authorized to access that model. These endpoints only require get_verified_user (any authenticated non-pending user) and validate that the model exists in the full unfiltered model list, but never check AccessGrants.has_access(). This is in direct contrast with the /ollama/api/chat endpoint (line 1101-1122) which correctly validates model …
The POST /api/v1/models/import endpoint allows users with the workspace.models_import permission to overwrite any existing model in the database, regardless of ownership. When an imported model's ID matches an existing model, the endpoint merges the attacker's payload over the existing model data and writes it to the database with no ownership or access grant validation. Additionally, filter_allowed_access_grants is never called, bypassing the access grant restrictions enforced on all other model mutation …
FolderForm uses model_config = ConfigDict(extra='allow'), which permits arbitrary fields to pass through Pydantic validation and be included in model_dump(exclude_unset=True). In insert_new_folder, the server-assigned user_id is placed at the start of the dict and then overwritten by the spread of form data:
All resource routers in Open WebUI (knowledge, models, notes, prompts, tools, skills) call filter_allowed_access_grants() before persisting access grants. This function strips principal_id: "" wildcard grants from users who lack the relevant sharing.public_ permission, and strips individual user grants from users who lack access_grants.allow_users permission. The channel router does not call filter_allowed_access_grants on either create or update paths. A non-admin user who can create group channels (or who owns a channel) …
Open WebUI supports model composition via base_model_id: a user-defined model (e.g., "Cheap Assistant") can reference an existing base model (e.g., "gpt-4-turbo-restricted") that provides the actual inference capability. When a user queries the composed model, the access control pipeline verifies the user has access to the composed model but never re-verifies access to the chained base model. Additionally, the model creation and import endpoints accept arbitrary base_model_id values without checking that …
When a user connects via Socket.IO, the connect handler authenticates them via JWT and stores their user record (including role) in the in-memory SESSION_POOL dictionary keyed by session ID. The heartbeat handler keeps the session alive indefinitely but only refreshes the last_seen_at timestamp — never the role. Role checks in the Yjs collaborative document handlers (ydoc:document:join, document_save_handler) consult the cached SESSION_POOL role rather than the database. Meanwhile, administrative role changes …
Open WebUI uses a REDIS_KEY_PREFIX (default open-webui) to namespace Redis keys, allowing multiple instances to safely share a single Redis backend. Every Redis key in the codebase uses this prefix — except the tool_servers and terminal_servers keys in utils/tools.py, which use bare key names. When two or more Open WebUI instances share a Redis database (a supported and documented deployment pattern, e.g., for multi-region deployments, blue-green setups, or cluster topologies), …
The is_user_channel_member function checks whether a ChannelMember row exists but does not check the is_active field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with is_active=False and status='left'. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls. The channel correctly disappears …
The _validate_collection_access function uses an incomplete allowlist that only enforces ownership checks for collections matching user-memory-* and file-* patterns. All other collection names pass through unchecked — including the system-level knowledge-bases meta-collection, which stores the IDs, names, and descriptions of every knowledge base on the instance. Any authenticated user can query this meta-collection directly via the retrieval query endpoints to obtain a global index of all knowledge bases across all …
Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traversal vulnerability.
The GET /api/v1/channels/{id}/members endpoint only checks membership for group and dm channel types (lines 467-469). For standard channels — including private ones — there is no channel_has_access check before returning the member list. Any authenticated user who knows a private channel's UUID can enumerate all users with access to that channel.
The get_sources_from_items function resolves file and knowledge base references into vector search queries during chat completion. Three of the five code paths perform vector store queries without any authorization check, allowing users to extract content from files and knowledge bases they do not have access to. | Path | Lines | Access Check | |——|——-|————-| | type: "file", full-context | 1044-1050 | ✅ has_access_to_file | | type: "file", non-full-context (default) …
An admin can inject arbitrary JavaScript into the Pending User Overlay Content that executes in the browser context of any pending user who views the overlay page. This could be used to: Session hijacking: Steal pending users' JWT tokens from cookies/localStorage Credential theft: Replace the pending overlay with a fake login form Phishing: Redirect pending users to malicious sites While this requires admin privileges to set the overlay content, it …
Excel file attachments are previewed in an unsafe way. A crafted XLSX file payload can be used to cause the sheetjs function sheet_to_html to embed an XSS payload into the generated HTML. This is subsequently added to the DOM unsanitized via @html causing the payload to trigger.
The POST /api/v1/retrieval/process/web endpoint accepts a user-supplied collection_name and an overwrite query parameter (default: True). It performs no authorization check on whether the calling user owns or has write access to the target collection. When overwrite=True, save_docs_to_vector_db calls VECTOR_DB_CLIENT.delete_collection() on the target collection before writing new content. Combined with the knowledge base enumeration vulnerability (separate report), an attacker can trivially discover any user's knowledge base UUID and then destroy or …
There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.
The LDAP authentication endpoint does not validate that the submitted password is non-empty before performing a Simple Bind against the LDAP server. Per RFC 4513 Section 5.1.2, a Simple Bind with a valid DN and an empty password constitutes an "unauthenticated simple authentication" — many LDAP servers (including OpenLDAP in default configuration and some Active Directory setups) return success (resultCode 0) for this operation. The LdapForm Pydantic model accepts password: …
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.11, there is a broken access control vulnerability in tool values. This issue has been patched in version 0.8.11
Any authenticated user can overwrite any file's content by ID through the POST /api/v1/retrieval/process/files/batch endpoint. The endpoint performs no ownership check, so a regular user with read access to a shared knowledge base can obtain file UUIDs via GET /api/v1/knowledge/{id}/files and then overwrite those files, escalating from read to write. The overwritten content is served to the LLM via RAG, meaning the attacker controls what the model tells other users.
Any authenticated user can read other users' private memories via /api/v1/retrieval/query/collection
An unsanitised filename field in the speech-to-text transcription endpoint allows any authenticated non-admin user to trigger a FileNotFoundError whose message — including the server's absolute DATA_DIR path — is returned verbatim in the HTTP 400 response body, confirming information disclosure on all default deployments.
An access control check is missing when deleting a file from a knowledge base. The only check being done is that the user has write access to the knowledge base (or is admin), but NOT that the file actually belongs to this knowledge base. It is thus possible to delete arbitrary files from arbitrary knowledge bases (as long as one knows the file id)