{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/open-webui/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["open-webui (\u003c= 0.8.12)"],"_cs_severities":["high"],"_cs_tags":["authentication-bypass","llm","owasp"],"_cs_type":"advisory","_cs_vendors":["Open WebUI"],"content_html":"\u003cp\u003eOpen 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid user credentials for the Open WebUI instance. This could be through credential stuffing, phishing, or other common methods.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Open WebUI instance using the obtained credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a POST request to the \u003ccode\u003e/api/openai/responses\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Open WebUI instance, upon receiving the request at \u003ccode\u003e/api/openai/responses\u003c/code\u003e, only verifies the user\u0026rsquo;s session.\u003c/li\u003e\n\u003cli\u003eDue to the missing access control checks, the request is forwarded to the upstream LLM provider, effectively bypassing the intended access restrictions.\u003c/li\u003e\n\u003cli\u003eThe upstream LLM provider processes the request using the specified model, even though the user lacks authorization.\u003c/li\u003e\n\u003cli\u003eThe attacker receives the response from the LLM, successfully interacting with a restricted model.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Open WebUI version 0.8.13 or later to patch CVE-2026-44556 and address the authentication bypass vulnerability.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI Unauthorized Model Access via Responses Endpoint\u0026rdquo; to identify potential exploitation attempts by monitoring POST requests to \u003ccode\u003e/api/openai/responses\u003c/code\u003e with potentially malicious model IDs.\u003c/li\u003e\n\u003cli\u003eReview Open WebUI access logs for any suspicious activity related to the \u003ccode\u003e/api/openai/responses\u003c/code\u003e endpoint, particularly requests from users who should not have access to specific models.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-08T19:45:53Z","date_published":"2026-05-08T19:45:53Z","id":"/briefs/2024-01-open-webui-auth-bypass/","summary":"The /responses endpoint in Open WebUI's OpenAI router lacks access control, allowing authenticated users to bypass per-model access controls and interact with any configured model, potentially leading to denial of service, model theft, and access policy bypass.","title":"Open WebUI /responses Endpoint Authentication Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-open-webui-auth-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Open WebUI (Formerly Ollama WebUI)"],"_cs_severities":["high"],"_cs_tags":["path-traversal","file-upload","web-application"],"_cs_type":"advisory","_cs_vendors":["Open WebUI"],"content_html":"\u003cp\u003eOpen 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 \u0026amp; Sean Segreti of KoreLogic, Inc. in March 2024, this flaw allows an attacker to upload files to arbitrary locations on the web server\u0026rsquo;s filesystem. The vulnerability stems from the application\u0026rsquo;s failure to properly validate or sanitize filenames during file uploads to the \u003ccode\u003e/rag/api/v1/doc\u003c/code\u003e endpoint. By exploiting this, malicious actors can use dot-segments (e.g., \u003ccode\u003e../../\u003c/code\u003e) 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 \u003ccode\u003eauthorized_keys\u003c/code\u003e for SSH access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker authenticates to the Open WebUI web interface.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts an HTTP POST request to the \u003ccode\u003e/rag/api/v1/doc\u003c/code\u003e endpoint, initiating a file upload.\u003c/li\u003e\n\u003cli\u003eThe attacker includes a malicious filename in the multipart form data, containing path traversal sequences (e.g., \u003ccode\u003e../../../../../../../../../../tmp/pwned.txt\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe Open WebUI server receives the request and extracts the unsanitized filename from the HTTP POST request.\u003c/li\u003e\n\u003cli\u003eThe server constructs a file path using the provided filename and the static \u003ccode\u003eUPLOAD_DIR\u003c/code\u003e variable.\u003c/li\u003e\n\u003cli\u003eThe server proceeds to write the contents of the uploaded file to the constructed file path, effectively bypassing intended directory restrictions.\u003c/li\u003e\n\u003cli\u003eA malicious actor can overwrite existing system files, such as \u003ccode\u003e.ssh/authorized_keys\u003c/code\u003e for unauthorized system access.\u003c/li\u003e\n\u003cli\u003eAlternatively, an attacker uploads a malicious model as a pickled python object to achieve remote code execution.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Open WebUI to a version beyond 0.1.123 which addresses the CVE-2026-44566 vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement input validation and sanitization on the server-side to prevent path traversal attacks during file uploads to mitigate the arbitrary file upload.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI Path Traversal File Upload\u0026rdquo; to identify exploitation attempts in web server logs.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for HTTP POST requests to the \u003ccode\u003e/rag/api/v1/doc\u003c/code\u003e endpoint with filenames containing path traversal sequences.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T18:30:00Z","date_published":"2024-07-03T18:30:00Z","id":"/briefs/2024-07-open-webui-upload-traversal/","summary":"Open WebUI version 0.1.105 is vulnerable to arbitrary file upload and path traversal, allowing attackers to upload files to arbitrary locations on the web server's filesystem by exploiting a lack of filename validation.","title":"Open WebUI Arbitrary File Upload and Path Traversal Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-07-open-webui-upload-traversal/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Open WebUI (Formerly Ollama WebUI) 0.1.105"],"_cs_severities":["high"],"_cs_tags":["authorization","web-application","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Open WebUI"],"content_html":"\u003cp\u003eOpen WebUI, formerly Ollama WebUI, version 0.1.105, suffers from an improper authorization control vulnerability. This flaw allows users with a \u0026lsquo;pending\u0026rsquo; status to bypass intended restrictions and make authenticated API calls as if they were authorized \u0026lsquo;user\u0026rsquo; roles. The vulnerability arises because the application\u0026rsquo;s API endpoints do not adequately validate the user\u0026rsquo;s role, relying solely on the presence of a valid JWT for authentication, while neglecting to verify the user\u0026rsquo;s assigned role. The vulnerability was discovered by Taylor Pennington of KoreLogic, Inc. This issue allows unapproved users to access sensitive data and functionality.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker registers a new user account on the Open WebUI platform with \u003ccode\u003enew sign-ups\u003c/code\u003e enabled. The new account is automatically assigned a \u003ccode\u003epending\u003c/code\u003e status.\u003c/li\u003e\n\u003cli\u003eThe application generates a JWT for the new user, despite their \u003ccode\u003epending\u003c/code\u003e status, and returns it to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts an HTTP GET request to the \u003ccode\u003e/ollama/api/tags\u003c/code\u003e endpoint, including the JWT in the \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eThe Open WebUI server receives the request and validates the JWT using the \u003ccode\u003eget_current_user\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eget_current_user\u003c/code\u003e function only checks the validity of the JWT but does not verify the user\u0026rsquo;s role, thus allowing the request to proceed.\u003c/li\u003e\n\u003cli\u003eThe server retrieves a list of available models without properly validating the user\u0026rsquo;s authorization.\u003c/li\u003e\n\u003cli\u003eThe server returns the list of available models in the HTTP response to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker can now access other regular user accessible endpoints.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI API Access by Pending User\u0026rdquo; to your SIEM to identify unauthorized API access attempts from users with a \u003ccode\u003epending\u003c/code\u003e role based on HTTP request headers and response codes.\u003c/li\u003e\n\u003cli\u003eApply the patch recommended by Open WebUI to utilize the \u003ccode\u003eget_verified_user()\u003c/code\u003e function instead of \u003ccode\u003eget_current_user()\u003c/code\u003e in all authenticated endpoints to enforce proper authorization checks as described in the Mitigation Recommendation section.\u003c/li\u003e\n\u003cli\u003eMonitor user registration requests to \u003ccode\u003e/api/v1/auths/signup\u003c/code\u003e using the \u0026ldquo;Detect Open WebUI User Registration\u0026rdquo; Sigma rule to track account creation attempts and potential abuse.\u003c/li\u003e\n\u003cli\u003eInvestigate and revoke any JWTs associated with \u003ccode\u003epending\u003c/code\u003e user accounts to prevent unauthorized access using the email IOC.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"/briefs/2024-07-open-webui-auth-bypass/","summary":"Open WebUI version 0.1.105 is vulnerable to an improper authorization control issue, where user accounts with a `pending` status can bypass authorization checks and make authenticated API calls as a `user` context due to the application failing to properly validate the user's role beyond JWT validation.","title":"Open WebUI Improper Authorization Control Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-07-open-webui-auth-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["open-webui (\u003c= 0.8.12)"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":["open-webui"],"content_html":"\u003cp\u003eOpen 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., \u0026lsquo;admin\u0026rsquo;) is cached in an in-memory \u003ccode\u003eSESSION_POOL\u003c/code\u003e. 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 \u003ccode\u003e6fdd19bf1\u003c/code\u003e) and likely all versions with the collaborative document (Yjs) Socket.IO handlers.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser B authenticates as an administrator and establishes a Socket.IO connection, which stores their \u003ccode\u003erole\u003c/code\u003e as \u003ccode\u003eadmin\u003c/code\u003e in the \u003ccode\u003eSESSION_POOL\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAdministrator A demotes User B to a regular user via the \u003ccode\u003ePOST /api/v1/users/{B_id}/update\u003c/code\u003e endpoint, modifying the user\u0026rsquo;s role in the database.\u003c/li\u003e\n\u003cli\u003eThe Socket.IO session remains active, and User B\u0026rsquo;s \u003ccode\u003eSESSION_POOL\u003c/code\u003e entry retains the stale \u003ccode\u003eadmin\u003c/code\u003e role.\u003c/li\u003e\n\u003cli\u003eUser B\u0026rsquo;s client continues sending \u003ccode\u003eheartbeat\u003c/code\u003e events to maintain the Socket.IO connection, refreshing only the \u003ccode\u003elast_seen_at\u003c/code\u003e timestamp in the \u003ccode\u003eSESSION_POOL\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eUser B sends a \u003ccode\u003eydoc:document:join\u003c/code\u003e event with the \u003ccode\u003edocument_id\u003c/code\u003e of a note belonging to another user (e.g., \u003ccode\u003enote:\u0026lt;victim_note_id\u0026gt;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe server-side handler at \u003ccode\u003esocket/main.py:538\u003c/code\u003e checks the cached role from the \u003ccode\u003eSESSION_POOL\u003c/code\u003e, incorrectly granting access due to the stale \u003ccode\u003eadmin\u003c/code\u003e role.\u003c/li\u003e\n\u003cli\u003eUser B now gains read access to the victim\u0026rsquo;s note, receives the full document state, and gets live updates.\u003c/li\u003e\n\u003cli\u003eUser B sends a \u003ccode\u003eydoc:document:update\u003c/code\u003e event, and the handler at \u003ccode\u003esocket/main.py:611\u003c/code\u003e bypasses authorization using the cached role, allowing User B to modify the victim\u0026rsquo;s note\u0026rsquo;s content.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized read and write access to any user\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply available patches or upgrade Open WebUI to a version that addresses CVE-2026-44553.\u003c/li\u003e\n\u003cli\u003eImplement a mechanism to invalidate Socket.IO sessions upon user role changes or deletions to prevent the use of stale privileges. Specifically, invalidate or update \u003ccode\u003eSESSION_POOL\u003c/code\u003e entries when user roles are modified via the \u003ccode\u003e/api/v1/users/{B_id}/update\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI Note Access Attempt with Stale Admin Session\u0026rdquo; to identify potential attempts to access notes using stale admin sessions.\u003c/li\u003e\n\u003cli\u003eReview and audit the implementation of the Socket.IO session management, particularly the \u003ccode\u003econnect\u003c/code\u003e and \u003ccode\u003eheartbeat\u003c/code\u003e handlers in \u003ccode\u003ebackend/open_webui/socket/main.py\u003c/code\u003e, to ensure proper role validation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"/briefs/2024-01-25-open-webui-privesc/","summary":"Open WebUI is vulnerable to privilege escalation; when a user connects via Socket.IO, their role is stored in an in-memory session pool, and administrative changes do not invalidate this session, allowing unauthorized access and modification of other users' notes after role revocation.","title":"Open WebUI Stale Admin Role Enables Post-Demotion Cross-User Note Access","url":"https://feed.craftedsignal.io/briefs/2024-01-25-open-webui-privesc/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["open-webui (\u003c= 0.8.12)"],"_cs_severities":["high"],"_cs_tags":["access-control","model-chaining","open-webui","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Open WebUI"],"content_html":"\u003cp\u003eOpen 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 \u003ccode\u003e6fdd19bf1\u003c/code\u003e) and likely all versions with the model chaining feature.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAdmin provisions a restricted model, such as \u003ccode\u003egpt-4-turbo-restricted\u003c/code\u003e, and configures access control policies.\u003c/li\u003e\n\u003cli\u003eAttacker, without access to the restricted model, crafts a \u003ccode\u003ePOST\u003c/code\u003e request to \u003ccode\u003e/api/v1/models/create\u003c/code\u003e with a payload defining a new model (e.g., \u003ccode\u003echeap-assistant\u003c/code\u003e) and setting its \u003ccode\u003ebase_model_id\u003c/code\u003e to the restricted model\u0026rsquo;s ID.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecreate\u003c/code\u003e endpoint lacks validation to ensure the attacker has access to the specified \u003ccode\u003ebase_model_id\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker now owns the \u003ccode\u003echeap-assistant\u003c/code\u003e model, which will pass the initial \u003ccode\u003echeck_model_access\u003c/code\u003e check.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a \u003ccode\u003ePOST\u003c/code\u003e request to \u003ccode\u003e/api/chat/completions\u003c/code\u003e, specifying the newly created \u003ccode\u003echeap-assistant\u003c/code\u003e model.\u003c/li\u003e\n\u003cli\u003eThe application resolves the \u003ccode\u003ebase_model_id\u003c/code\u003e of \u003ccode\u003echeap-assistant\u003c/code\u003e to \u003ccode\u003egpt-4-turbo-restricted\u003c/code\u003e within \u003ccode\u003emain.py:1696\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application rewrites the \u003ccode\u003epayload[\u0026quot;model\u0026quot;]\u003c/code\u003e to the base model ID, and dispatches the upstream request using the admin-configured API key.\u003c/li\u003e\n\u003cli\u003eThe attacker receives responses from the restricted model, successfully circumventing the intended access restrictions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Open WebUI Model Creation with External BaseModelID\u003c/code\u003e to detect attempts to create models with \u003ccode\u003ebase_model_id\u003c/code\u003e pointing to existing models, and tune the false positives for your environment.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Open WebUI Chat Completion Request Using Custom Model with BaseModelID\u003c/code\u003e to detect chat completion requests using a custom model with a \u003ccode\u003ebase_model_id\u003c/code\u003e set.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Open WebUI that includes proper access control validation for \u003ccode\u003ebase_model_id\u003c/code\u003e during model creation to remediate CVE-2026-44555.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-open-webui-model-bypass/","summary":"Open WebUI is vulnerable to an access control bypass due to improper model chaining, allowing a regular user to create a model that chains to a restricted base model and query it using the admin's API key, bypassing access restrictions.","title":"Open WebUI Model Chaining Access Control Bypass","url":"https://feed.craftedsignal.io/briefs/2024-01-02-open-webui-model-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — Open-Webui","version":"https://jsonfeed.org/version/1.1"}