Open-Webui — CraftedSignal Threat Feed

Open WebUI /responses Endpoint Authentication Bypass Vulnerability

hello@craftedsignal.io — Fri, 08 May 2026 19:45:53 +0000

Open WebUI versions 0.8.12 and earlier contain an authentication bypass vulnerability in the /responses endpoint of the OpenAI router. This endpoint, intended as a proxy to upstream LLM providers, fails to enforce per-model access controls. While the primary chat completion endpoint (generate_chat_completion) correctly validates model ownership, group membership, and AccessGrants, the /responses endpoint only verifies a valid user session. Consequently, any authenticated user can interact with any model configured on the Open WebUI instance, regardless of their assigned roles or group memberships, by sending a crafted POST request to /api/openai/responses with an arbitrary model ID. This circumvents intended access restrictions and poses risks to service availability, model security, and policy enforcement.

Attack Chain

An attacker obtains valid user credentials for the Open WebUI instance. This could be through credential stuffing, phishing, or other common methods.
The attacker authenticates to the Open WebUI instance using the obtained credentials.
The attacker crafts a POST request to the /api/openai/responses endpoint.
The attacker includes an arbitrary model ID in the POST request body, specifying a model they do not have explicit access to under normal access control policies.
The Open WebUI instance, upon receiving the request at /api/openai/responses, only verifies the user’s session.
Due to the missing access control checks, the request is forwarded to the upstream LLM provider, effectively bypassing the intended access restrictions.
The upstream LLM provider processes the request using the specified model, even though the user lacks authorization.
The attacker receives the response from the LLM, successfully interacting with a restricted model.

Impact

Successful exploitation of this vulnerability can have significant consequences. Unauthorized users can submit resource-intensive requests to expensive models, leading to Model Denial of Service (OWASP LLM04) by exhausting API budgets or rate limits, potentially causing total service disruption for legitimate users. Furthermore, if the instance proxies access to fine-tuned or self-hosted models, unauthorized interaction can lead to Model Theft (OWASP LLM10), enabling capability extraction or model distillation. Finally, the vulnerability undermines existing access control systems, preventing administrators from enforcing cost-tier restrictions, team-based model assignments, or compliance boundaries.

Recommendation

Upgrade to Open WebUI version 0.8.13 or later to patch CVE-2026-44556 and address the authentication bypass vulnerability.
Deploy the Sigma rule “Detect Open WebUI Unauthorized Model Access via Responses Endpoint” to identify potential exploitation attempts by monitoring POST requests to /api/openai/responses with potentially malicious model IDs.
Review Open WebUI access logs for any suspicious activity related to the /api/openai/responses endpoint, particularly requests from users who should not have access to specific models.

Open WebUI Arbitrary File Upload and Path Traversal Vulnerability

hello@craftedsignal.io — Wed, 03 Jul 2024 18:30:00 +0000

Open WebUI version 0.1.105, formerly known as Ollama WebUI, is susceptible to an arbitrary file upload and path traversal vulnerability. Discovered by Jaggar Henry & Sean Segreti of KoreLogic, Inc. in March 2024, this flaw allows an attacker to upload files to arbitrary locations on the web server’s filesystem. The vulnerability stems from the application’s failure to properly validate or sanitize filenames during file uploads to the /rag/api/v1/doc endpoint. By exploiting this, malicious actors can use dot-segments (e.g., ../../) in the file path to traverse out of the intended uploads directory. Successful exploitation enables the uploading of malicious models, such as pickled Python objects, or the modification of system files like authorized_keys for SSH access.

Attack Chain

An attacker authenticates to the Open WebUI web interface.
The attacker crafts an HTTP POST request to the /rag/api/v1/doc endpoint, initiating a file upload.
The attacker includes a malicious filename in the multipart form data, containing path traversal sequences (e.g., ../../../../../../../../../../tmp/pwned.txt).
The Open WebUI server receives the request and extracts the unsanitized filename from the HTTP POST request.
The server constructs a file path using the provided filename and the static UPLOAD_DIR variable.
The server proceeds to write the contents of the uploaded file to the constructed file path, effectively bypassing intended directory restrictions.
A malicious actor can overwrite existing system files, such as .ssh/authorized_keys for unauthorized system access.
Alternatively, an attacker uploads a malicious model as a pickled python object to achieve remote code execution.

Impact

Successful exploitation of this vulnerability, identified as CVE-2026-44566, can lead to arbitrary code execution on the server. An attacker could gain unauthorized access to the system, potentially leading to data breaches, system compromise, or denial of service. The vulnerable version, 0.1.105, is actively exploitable, and organizations using this version are at risk. The targeted platform observed during analysis was Debian GNU/Linux 12.

Recommendation

Upgrade Open WebUI to a version beyond 0.1.123 which addresses the CVE-2026-44566 vulnerability.
Implement input validation and sanitization on the server-side to prevent path traversal attacks during file uploads to mitigate the arbitrary file upload.
Deploy the Sigma rule “Detect Open WebUI Path Traversal File Upload” to identify exploitation attempts in web server logs.
Monitor web server logs for HTTP POST requests to the /rag/api/v1/doc endpoint with filenames containing path traversal sequences.

Open WebUI Improper Authorization Control Vulnerability

hello@craftedsignal.io — Wed, 03 Jul 2024 12:00:00 +0000

Open WebUI, formerly Ollama WebUI, version 0.1.105, suffers from an improper authorization control vulnerability. This flaw allows users with a ‘pending’ status to bypass intended restrictions and make authenticated API calls as if they were authorized ‘user’ roles. The vulnerability arises because the application’s API endpoints do not adequately validate the user’s role, relying solely on the presence of a valid JWT for authentication, while neglecting to verify the user’s assigned role. The vulnerability was discovered by Taylor Pennington of KoreLogic, Inc. This issue allows unapproved users to access sensitive data and functionality.

Attack Chain

Attacker registers a new user account on the Open WebUI platform with new sign-ups enabled. The new account is automatically assigned a pending status.
The application generates a JWT for the new user, despite their pending status, and returns it to the attacker.
The attacker crafts an HTTP GET request to the /ollama/api/tags endpoint, including the JWT in the Authorization header.
The Open WebUI server receives the request and validates the JWT using the get_current_user function.
The get_current_user function only checks the validity of the JWT but does not verify the user’s role, thus allowing the request to proceed.
The server retrieves a list of available models without properly validating the user’s authorization.
The server returns the list of available models in the HTTP response to the attacker.
The attacker can now access other regular user accessible endpoints.

Impact

Successful exploitation of this vulnerability allows unauthorized users to access sensitive information such as available models and potentially other resources intended only for authorized users. This could lead to information disclosure, unauthorized use of resources, and further compromise of the system. This issue affects Open WebUI installations that have enabled new user sign-ups without properly verifying user roles, potentially impacting all users on the platform.

Recommendation

Deploy the Sigma rule “Detect Open WebUI API Access by Pending User” to your SIEM to identify unauthorized API access attempts from users with a pending role based on HTTP request headers and response codes.
Apply the patch recommended by Open WebUI to utilize the get_verified_user() function instead of get_current_user() in all authenticated endpoints to enforce proper authorization checks as described in the Mitigation Recommendation section.
Monitor user registration requests to /api/v1/auths/signup using the “Detect Open WebUI User Registration” Sigma rule to track account creation attempts and potential abuse.
Investigate and revoke any JWTs associated with pending user accounts to prevent unauthorized access using the email IOC.

Open WebUI Stale Admin Role Enables Post-Demotion Cross-User Note Access

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

Open WebUI, a web interface for large language models, is susceptible to a privilege escalation vulnerability stemming from how it manages user sessions via Socket.IO. Specifically, when a user establishes a connection, their role (e.g., ‘admin’) is cached in an in-memory SESSION_POOL. Crucially, subsequent administrative actions like role revocation or user deletion, performed through HTTP endpoints, do not invalidate existing Socket.IO sessions. As a result, a user who has been demoted or deleted can retain their previous admin privileges within the active Socket.IO session indefinitely, so long as they maintain the connection via heartbeats. This vulnerability impacts current main branch (commit 6fdd19bf1) and likely all versions with the collaborative document (Yjs) Socket.IO handlers.

Attack Chain

User B authenticates as an administrator and establishes a Socket.IO connection, which stores their role as admin in the SESSION_POOL.
Administrator A demotes User B to a regular user via the POST /api/v1/users/{B_id}/update endpoint, modifying the user’s role in the database.
The Socket.IO session remains active, and User B’s SESSION_POOL entry retains the stale admin role.
User B’s client continues sending heartbeat events to maintain the Socket.IO connection, refreshing only the last_seen_at timestamp in the SESSION_POOL.
User B sends a ydoc:document:join event with the document_id of a note belonging to another user (e.g., note:).
The server-side handler at socket/main.py:538 checks the cached role from the SESSION_POOL, incorrectly granting access due to the stale admin role.
User B now gains read access to the victim’s note, receives the full document state, and gets live updates.
User B sends a ydoc:document:update event, and the handler at socket/main.py:611 bypasses authorization using the cached role, allowing User B to modify the victim’s note’s content.

Impact

Successful exploitation of this vulnerability allows unauthorized read and write access to any user’s notes. This occurs even after admin privileges have been legitimately revoked. The attacker only needs to maintain an active Socket.IO connection established while they had administrative rights, which is trivial as heartbeats keep the session alive indefinitely. This grants a false sense of security to administrators who revoke privileges, as the revocation only affects HTTP access but not real-time collaborative access.

Recommendation

Apply available patches or upgrade Open WebUI to a version that addresses CVE-2026-44553.
Implement a mechanism to invalidate Socket.IO sessions upon user role changes or deletions to prevent the use of stale privileges. Specifically, invalidate or update SESSION_POOL entries when user roles are modified via the /api/v1/users/{B_id}/update endpoint.
Deploy the Sigma rule “Detect Open WebUI Note Access Attempt with Stale Admin Session” to identify potential attempts to access notes using stale admin sessions.
Review and audit the implementation of the Socket.IO session management, particularly the connect and heartbeat handlers in backend/open_webui/socket/main.py, to ensure proper role validation.

Open WebUI Model Chaining Access Control Bypass

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Open WebUI, a web interface for Large Language Models, is susceptible to an access control vulnerability via its model chaining feature. This feature allows users to create custom models that reference existing base models for inference. The vulnerability arises because access controls are only applied to the user-facing model, not the chained base model. An attacker with default model creation permissions can exploit this flaw to create a model that chains to a restricted or premium base model, effectively bypassing intended access restrictions and querying the restricted model using the admin-configured API key. This issue affects the current main branch (commit 6fdd19bf1) and likely all versions with the model chaining feature.

Attack Chain

Admin provisions a restricted model, such as gpt-4-turbo-restricted, and configures access control policies.
Attacker, without access to the restricted model, crafts a POST request to /api/v1/models/create with a payload defining a new model (e.g., cheap-assistant) and setting its base_model_id to the restricted model’s ID.
The create endpoint lacks validation to ensure the attacker has access to the specified base_model_id.
The attacker now owns the cheap-assistant model, which will pass the initial check_model_access check.
The attacker sends a POST request to /api/chat/completions, specifying the newly created cheap-assistant model.
The application resolves the base_model_id of cheap-assistant to gpt-4-turbo-restricted within main.py:1696.
The application rewrites the payload["model"] to the base model ID, and dispatches the upstream request using the admin-configured API key.
The attacker receives responses from the restricted model, successfully circumventing the intended access restrictions.

Impact

This vulnerability allows unauthorized access to restricted models, potentially leading to increased costs on pay-per-token backends such as OpenAI or Azure, as the admin’s API key is used for unauthorized requests. It also creates a false sense of security, as access restrictions appear to work through the standard model selector but are ineffective against user-created chains. The vulnerability can lead to direct cost impact on pay-per-token backends and erode trust in the configured access controls.

Recommendation

Deploy the Sigma rule Detect Open WebUI Model Creation with External BaseModelID to detect attempts to create models with base_model_id pointing to existing models, and tune the false positives for your environment.
Deploy the Sigma rule Detect Open WebUI Chat Completion Request Using Custom Model with BaseModelID to detect chat completion requests using a custom model with a base_model_id set.
Upgrade to a patched version of Open WebUI that includes proper access control validation for base_model_id during model creation to remediate CVE-2026-44555.