Advisories for Pypi/Open-Webui package

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)

open-webui v0.6.33 is vulnerable to Incorrect Access Control. The API /api/tasks/stop/ directly accesses and cancels tasks without verifying user ownership, enabling attackers (a normal user) to stop arbitrary LLM response tasks.

A Server-Side Request Forgery (SSRF) vulnerability in Open WebUI allows any authenticated user to force the server to make HTTP requests to arbitrary URLs. This can be exploited to access cloud metadata endpoints (AWS/GCP/Azure), scan internal networks, access internal services behind firewalls, and exfiltrate sensitive information. No special permissions beyond basic authentication are required.

The functionality that inserts custom prompts into the chat window is vulnerable to DOM XSS when 'Insert Prompt as Rich Text' is enabled, since the prompt body is assigned to the DOM sink .innerHtml without sanitisation. Any user with permissions to create prompts can abuse this to plant a payload that could be triggered by other users if they run the corresponding / command to insert the prompt.

Open WebUI v0.6.33 and below contains a code injection vulnerability in the Direct Connections feature that allows malicious external model servers to execute arbitrary JavaScript in victim browsers via Server-Sent Event (SSE) execute events. This leads to authentication token theft, complete account takeover, and when chained with the Functions API, enables remote code execution on the backend server. The attack requires the victim to enable Direct Connections (disabled by default) …

A Stored Cross-Site Scripting (XSS) vulnerability exists in the chat file upload functionality of open-webui/open-webui version 0.3.8. An attacker can inject malicious content into a file, which, when accessed by a victim through a URL or shared chat, executes JavaScript in the victim's browser. This can lead to user data theft, session hijacking, malware distribution, and phishing attacks.

In version v0.3.8 of open-webui/open-webui, sensitive actions such as deleting and resetting are performed using the GET method. This vulnerability allows an attacker to perform Cross-Site Request Forgery (CSRF) attacks, where an unaware user can unintentionally perform sensitive actions by simply visiting a malicious site or through top-level navigation. The affected endpoints include /rag/api/v1/reset, /rag/api/v1/reset/db, /api/v1/memories/reset, and /rag/api/v1/reset/uploads. This impacts both the availability and integrity of the application.

A vulnerability in open-webui/open-webui version 0.3.8 allows an attacker with a user-level account to perform a session fixation attack. The session cookie for all users is set with the default SameSite=Lax and does not have the Secure flag enabled, allowing the session cookie to be sent over HTTP to a cross-origin domain. An attacker can exploit this by embedding a malicious markdown image in a chat, which, when viewed by …

In version v0.3.32 of open-webui/open-webui, the application allows users to submit large payloads in the email and password fields during the sign-in process due to the lack of character length validation on these inputs. This vulnerability can lead to a Denial of Service (DoS) condition when a user submits excessively large strings, exhausting server resources such as CPU, memory, and disk space, and rendering the service unavailable for legitimate users. …

In version 0.3.32 of open-webui/open-webui, the absence of authentication mechanisms allows any unauthenticated attacker to access the api/v1/utils/code/format endpoint. If a malicious actor sends a POST request with an excessively high volume of content, the server could become completely unresponsive. This could lead to severe performance issues, causing the server to become unresponsive or experience significant degradation, ultimately resulting in service interruptions for legitimate users.

A vulnerability in open-webui/open-webui v0.3.8 allows an unauthenticated attacker to sign up with excessively large text in the 'name' field, causing the Admin panel to become unresponsive. This prevents administrators from performing essential user management actions such as deleting, editing, or adding users. The vulnerability can also be exploited by authenticated users with low privileges, leading to the same unresponsive state in the Admin panel.

A vulnerability in open-webui/open-webui version 79778fa allows an attacker to cause a Denial of Service (DoS) by uploading a file with a malformed multipart boundary. By appending a large number of characters to the end of the multipart boundary, the server continuously processes each character, rendering the application inaccessible. This issue can prevent all users from accessing the application until the server recovers.

A Denial of Service (DoS) vulnerability exists in open-webui/open-webui version 0.3.21. This vulnerability affects multiple endpoints, including /ollama/models/upload, /audio/api/v1/transcriptions, and /rag/api/v1/doc. The application processes multipart boundaries without authentication, leading to resource exhaustion. By appending additional characters to the multipart boundary, an attacker can cause the server to parse each byte of the boundary, ultimately leading to service unavailability. This vulnerability can be exploited remotely, resulting in high CPU and memory …

A stored cross-site scripting (XSS) vulnerability exists in open-webui/open-webui version 0.3.8. The vulnerability is present in the /api/v1/models/add endpoint, where the model description field is improperly sanitized before being rendered in chat. This allows an attacker to inject malicious scripts that can be executed by any user, including administrators, potentially leading to arbitrary code execution.

In version v0.3.10 of open-webui/open-webui, the api/v1/utils/pdf endpoint lacks authentication mechanisms, allowing unauthenticated attackers to access the PDF generation service. This vulnerability can be exploited by sending a POST request with an excessively large payload, potentially leading to server resource exhaustion and denial of service (DoS). Additionally, unauthorized users can misuse the endpoint to generate PDFs without verification, resulting in service misuse and potential operational and financial impacts.

In version 0.3.32 of open-webui, the application uses a vulnerable version of the starlette package through its dependency on fastapi. The starlette package versions <=0.49 are susceptible to uncontrolled resource consumption, which can be exploited to cause a denial of service through memory exhaustion. This issue is addressed in fastapi version 0.115.3.

The /openai/models endpoint in open-webui/open-webui version 0.3.8 is vulnerable to Server-Side Request Forgery (SSRF). An attacker can change the OpenAI URL to any URL without checks, causing the endpoint to send a request to the specified URL and return the output. This vulnerability allows the attacker to access internal services and potentially gain command execution by accessing instance secrets.

In version v0.3.8 of open-webui/open-webui, improper access control vulnerabilities allow an attacker to view any prompts. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the /api/v1/prompts/ interface to retrieve all prompt information created by the admin, which includes the ID values. Subsequently, the attacker can exploit the /api/v1/prompts/command/{command_id} interface to obtain arbitrary prompt information.

In version 0.3.8 of open-webui, an endpoint for converting markdown to HTML is exposed without authentication. A maliciously crafted markdown payload can cause the server to spend excessive time converting it, leading to a denial of service. The server becomes unresponsive to other requests until the conversion is complete.

A vulnerability in open-webui/open-webui versions <= 0.3.8 allows remote code execution by non-admin users via Cross-Site Request Forgery (CSRF). The application uses cookies with the SameSite attribute set to lax for authentication and lacks CSRF tokens. This allows an attacker to craft a malicious HTML that, when accessed by a victim, can modify the Python code of an existing pipeline and execute arbitrary code with the victim's privileges.

An improper access control vulnerability in open-webui/open-webui v0.3.8 allows an attacker to view admin details. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the /api/v1/auths/admin/details interface to retrieve the first admin (owner) details.

OpenWebUI version 0.3.0 contains a vulnerability in the audio API endpoint /audio/api/v1/transcriptions that allows for arbitrary file upload. The application performs insufficient validation on the file.content_type and allows user-controlled filenames, leading to a path traversal vulnerability. This can be exploited by an authenticated user to overwrite critical files within the Docker container, potentially leading to remote code execution as the root user.

In version 0.3.8 of open-webui/open-webui, an arbitrary file write vulnerability exists in the download_model endpoint. When deployed on Windows, the application improperly handles file paths, allowing an attacker to manipulate the file path to write files to arbitrary locations on the server's filesystem. This can result in overwriting critical system or application files, causing denial of service, or potentially achieving remote code execution (RCE). RCE can allow an attacker to …

In open-webui version 0.3.8, the endpoint /models/upload is vulnerable to arbitrary file write due to improper handling of user-supplied filenames. The vulnerability arises from the usage of file_path = f"{UPLOAD_DIR}/{file.filename}" without proper input validation or sanitization. An attacker can exploit this by manipulating the file.filename parameter to include directory traversal sequences, causing the resulting file_path to escape the intended UPLOAD_DIR and potentially overwrite arbitrary files on the system. This can …

An improper access control vulnerability in open-webui/open-webui v0.3.8 allows attackers to view and delete any files. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the GET /api/v1/files/ interface to retrieve information on all files uploaded by users, which includes the ID values. The attacker can then use the GET /api/v1/files/{file_id} interface to obtain information on any file and the DELETE /api/v1/files/{file_id} …

In open-webui/open-webui version v0.3.8, there is an improper privilege management vulnerability. The application allows an attacker, acting as an admin, to delete other administrators via the API endpoint http://0.0.0.0:8080/api/v1/users/{uuid_administrator}. This action is restricted by the user interface but can be performed through direct API calls.

This advisory duplicates another.

This advisory duplicates another.

This advisory duplicates another.

An Insecure Direct Object Reference (IDOR) vulnerability exists in open-webui/open-webui version v0.3.8. The vulnerability occurs in the API endpoint http://0.0.0.0:3000/api/v1/memories/{id}/update, where the decentralization design is flawed, allowing attackers to edit other users' memories without proper authorization.

In version v0.3.8 of open-webui/open-webui, the endpoint /api/pipelines/upload is vulnerable to arbitrary file write and delete due to unsanitized file.filename concatenation with CACHE_DIR. This vulnerability allows attackers to overwrite and delete system files, potentially leading to remote code execution.

An information disclosure vulnerability exists in open-webui version 0.3.8. The vulnerability is related to the embedding model update feature under admin settings. When a user updates the model path, the system checks if the file exists and provides different error messages based on the existence and configuration of the file. This behavior allows an attacker to enumerate file names and traverse directories by observing the error messages, leading to potential …

Attackers can craft a malicious prompt that coerces the language model into executing arbitrary JavaScript in the context of the web page.