{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/open-webui--0.8.12/","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 (\u003c= 0.8.12)"],"_cs_severities":["critical"],"_cs_tags":["authentication-bypass","ldap","open-webui"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpen WebUI is vulnerable to an LDAP authentication bypass. The LDAP authentication endpoint does not validate that the submitted password is non-empty before performing a Simple Bind against the LDAP server. This vulnerability exists because the \u003ccode\u003eLdapForm\u003c/code\u003e Pydantic model accepts an empty string for the password field without any minimum length constraint. Subsequently, the \u003ccode\u003eConnection.bind()\u003c/code\u003e call succeeds on vulnerable LDAP servers, and the application issues a full session token for the target user. The issue affects the current main branch (commit \u003ccode\u003e6fdd19bf1\u003c/code\u003e) and likely all versions with LDAP authentication support. Exploitation requires that LDAP is enabled and the underlying LDAP server accepts unauthenticated simple binds with empty passwords, which is the default configuration for OpenLDAP and some Active Directory setups.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eLDAP authentication is enabled on the Open WebUI instance (\u003ccode\u003eENABLE_LDAP=True\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a valid LDAP username.\u003c/li\u003e\n\u003cli\u003eThe underlying LDAP server accepts unauthenticated simple binds (OpenLDAP default, some AD configs).\u003c/li\u003e\n\u003cli\u003eAttacker sends a POST request to \u003ccode\u003e/api/v1/auths/ldap\u003c/code\u003e with the target username and an empty password.\u003c/li\u003e\n\u003cli\u003eThe application\u0026rsquo;s DN bind succeeds, finding the target user via LDAP search.\u003c/li\u003e\n\u003cli\u003eThe application attempts a user bind using the provided (empty) password.\u003c/li\u003e\n\u003cli\u003eThe LDAP server returns success for the unauthenticated bind due to the empty password.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eauthenticate_user_by_email\u003c/code\u003e issues a full session token for the target user, granting complete account access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows a complete authentication bypass, enabling attackers to take over any LDAP user account without knowing the password, including admin accounts if they authenticate via LDAP. The vulnerability can be exploited with zero interaction from the victim and without rate limiting on the LDAP endpoint.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the mitigations recommended in GHSA-2r4p-jpmg-48f4 to prevent empty passwords from being used in LDAP authentication.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI LDAP Authentication Bypass Attempt\u0026rdquo; to monitor for POST requests to the \u003ccode\u003e/api/v1/auths/ldap\u003c/code\u003e endpoint with an empty password field, indicating a potential exploit attempt.\u003c/li\u003e\n\u003cli\u003eEnsure the LDAP server is configured to reject unauthenticated simple binds with empty passwords.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for POST requests to \u003ccode\u003e/api/v1/auths/ldap\u003c/code\u003e (webserver log source) and correlate with other authentication-related events.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-08T19:38:31Z","date_published":"2026-05-08T19:38:31Z","id":"/briefs/2024-01-24-open-webui-ldap-bypass/","summary":"Open WebUI is vulnerable to an LDAP authentication bypass where the LDAP authentication endpoint does not validate that the submitted password is non-empty before performing a Simple Bind against the LDAP server, potentially granting attackers complete account access.","title":"Open WebUI LDAP Empty Password Authentication Bypass","url":"https://feed.craftedsignal.io/briefs/2024-01-24-open-webui-ldap-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)","Redis"],"_cs_severities":["high"],"_cs_tags":["cache-poisoning","redis","open-webui","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Redis"],"content_html":"\u003cp\u003eOpen WebUI, a web interface for LLMs, is susceptible to a cross-instance cache poisoning vulnerability (CVE-2026-44552) when multiple instances share a Redis backend. This issue stems from missing \u003ccode\u003eREDIS_KEY_PREFIX\u003c/code\u003e usage for the \u003ccode\u003etool_servers\u003c/code\u003e and \u003ccode\u003eterminal_servers\u003c/code\u003e keys in \u003ccode\u003eutils/tools.py\u003c/code\u003e. Specifically, lines 841, 850, 976, and 986 do not utilize the key prefix. As a result, an attacker with admin privileges on one instance can overwrite the cache values used by other instances. This vulnerability affects the current main branch (commit \u003ccode\u003e6fdd19bf1\u003c/code\u003e) and likely all versions since the tool server/terminal server Redis cache was introduced. This is a critical issue because it undermines the multi-instance isolation that \u003ccode\u003eREDIS_KEY_PREFIX\u003c/code\u003e aims to provide, potentially impacting blue-green deployments, multi-region setups, and cluster topologies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains admin access to Open WebUI Instance A, either through legitimate means or by exploiting vulnerabilities like LDAP empty-password or stale-admin-role issues.\u003c/li\u003e\n\u003cli\u003eThe attacker configures a malicious tool server on Instance A, pointing to \u003ccode\u003ehttps://attacker-controlled.example.com/openapi.json\u003c/code\u003e. This configuration triggers a write to the \u003ccode\u003etool_servers\u003c/code\u003e Redis key without the \u003ccode\u003eREDIS_KEY_PREFIX\u003c/code\u003e (line 841 in \u003ccode\u003eutils/tools.py\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eUsers on Open WebUI Instance B attempt to query available tools. This action triggers a read from the same unprefixed \u003ccode\u003etool_servers\u003c/code\u003e Redis key (line 850 in \u003ccode\u003eutils/tools.py\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInstance B retrieves the attacker\u0026rsquo;s poisoned tool server list from Instance A, which now includes the attacker\u0026rsquo;s server, possibly replacing legitimate tool servers.\u003c/li\u003e\n\u003cli\u003eA user on Instance B invokes a tool. The tool call payload, including chat content, user identity, and OAuth tokens, is sent to the attacker-controlled server.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server responds with arbitrary tool outputs, which are then fed back into Instance B\u0026rsquo;s LLM context.\u003c/li\u003e\n\u003cli\u003eThe malicious tool output is treated as trusted data within Instance B\u0026rsquo;s LLM, enabling prompt injection and misinformation delivery.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages prompt injection and misinformation delivery to further compromise Instance B and exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to cross-instance cache poisoning, where one instance\u0026rsquo;s admin can affect all users of another instance sharing the same Redis backend. Sensitive data, including chat content and user identity, can be exfiltrated to an attacker-controlled server. Furthermore, the attacker can inject malicious content into the victim instance\u0026rsquo;s LLM context, leading to prompt injection attacks. This undermines the intended isolation between Open WebUI instances and can lead to significant data breaches and system compromise. The vulnerability\u0026rsquo;s silent failure mode makes detection difficult for victim instances.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI Tool Server Configuration Change\u0026rdquo; to monitor for unauthorized changes to the \u003ccode\u003etool_servers\u003c/code\u003e key (rule below).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Open WebUI Terminal Server Configuration Change\u0026rdquo; to monitor for unauthorized changes to the \u003ccode\u003eterminal_servers\u003c/code\u003e key (rule below).\u003c/li\u003e\n\u003cli\u003eApply available patches or upgrades to Open WebUI to versions beyond 0.8.12 as soon as they are released to address CVE-2026-44552.\u003c/li\u003e\n\u003cli\u003eRestrict admin access to Open WebUI instances and enforce strong password policies.\u003c/li\u003e\n\u003cli\u003eReview and audit existing Open WebUI deployments to ensure proper configuration and security best practices.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-09T12:00:00Z","date_published":"2024-05-09T12:00:00Z","id":"/briefs/2024-05-open-webui-cache-poisoning/","summary":"Open WebUI versions up to 0.8.12 are vulnerable to cross-instance cache poisoning when multiple instances share a Redis backend, allowing an attacker with admin access on one instance to overwrite cache values used by other instances, leading to data exfiltration and prompt injection attacks.","title":"Open WebUI Cross-Instance Cache Poisoning Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-open-webui-cache-poisoning/"},{"_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":["rag","poisoning","web-application"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eOpen WebUI, a retrieval-augmented generation (RAG) application, is susceptible to unauthorized knowledge base modification. The vulnerability lies in the \u003ccode\u003eprocess_web\u003c/code\u003e endpoint within \u003ccode\u003ebackend/open_webui/routers/retrieval.py\u003c/code\u003e. Specifically, the \u003ccode\u003ePOST /api/v1/retrieval/process/web\u003c/code\u003e endpoint lacks authorization checks, which allows any authenticated user with knowledge of a target knowledge base UUID to overwrite it with arbitrary content. This is possible due to the \u003ccode\u003eoverwrite\u003c/code\u003e parameter, which defaults to \u003ccode\u003eTrue\u003c/code\u003e and triggers the deletion of the existing vector collection before new content is written via the \u003ccode\u003esave_docs_to_vector_db\u003c/code\u003e function. The issue affects the current main branch (commit \u003ccode\u003e6fdd19bf1\u003c/code\u003e) and likely all versions with RAG functionality. An attacker can leverage this vulnerability to poison the RAG system by injecting malicious content into the knowledge base.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains a valid user account on the Open WebUI instance.\u003c/li\u003e\n\u003cli\u003eAttacker discovers the victim\u0026rsquo;s knowledge base UUID, potentially through the \u003ccode\u003eknowledge-bases\u003c/code\u003e meta-collection (as mentioned in the report).\u003c/li\u003e\n\u003cli\u003eAttacker crafts a POST request to the \u003ccode\u003e/api/v1/retrieval/process/web\u003c/code\u003e endpoint, setting the \u003ccode\u003ecollection_name\u003c/code\u003e parameter to the victim\u0026rsquo;s KB UUID and ensures \u003ccode\u003eoverwrite=true\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe POST request includes a \u003ccode\u003eurl\u003c/code\u003e parameter pointing to an attacker-controlled URL containing malicious content.\u003c/li\u003e\n\u003cli\u003eThe Open WebUI server fetches the content from the attacker-controlled URL.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esave_docs_to_vector_db\u003c/code\u003e function is called, which first deletes the existing vector collection associated with the victim\u0026rsquo;s knowledge base.\u003c/li\u003e\n\u003cli\u003eThe fetched content from the attacker\u0026rsquo;s URL is then embedded and stored as the new content for the knowledge base.\u003c/li\u003e\n\u003cli\u003eWhen the victim queries their knowledge base, the RAG system returns the attacker-controlled content, leading to potential misinformation or malicious actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to data destruction, where the victim\u0026rsquo;s original knowledge base embeddings are permanently deleted from the vector store. Furthermore, the RAG system is poisoned with attacker-controlled content, causing the LLM to return misleading or malicious responses. This can enable indirect prompt injection and manipulation of the victim\u0026rsquo;s LLM behavior. The poisoned content persists until the knowledge base is rebuilt from the original source files, creating a persistent vulnerability. Versions of open-webui up to and including 0.8.12 are affected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply authorization checks to the \u003ccode\u003e/api/v1/retrieval/process/web\u003c/code\u003e endpoint to verify that the user has write access to the target collection, mitigating CVE-2026-44554.\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for POST requests to \u003ccode\u003e/api/v1/retrieval/process/web\u003c/code\u003e with suspicious \u003ccode\u003ecollection_name\u003c/code\u003e parameters, using the Sigma rule \u0026ldquo;Detect Open WebUI Unauthorized Collection Overwrite Attempt\u0026rdquo; to identify potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eInspect network traffic for connections to suspicious URLs used in the \u003ccode\u003eurl\u003c/code\u003e parameter of the \u003ccode\u003e/api/v1/retrieval/process/web\u003c/code\u003e endpoint, such as the IOC \u003ccode\u003ehttps://attacker.com/poison\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-18T12:00:00Z","date_published":"2024-01-18T12:00:00Z","id":"/briefs/2024-01-18-open-webui-rag-poisoning/","summary":"Open WebUI is vulnerable to knowledge base destruction and RAG poisoning due to a lack of authorization checks on the `/api/v1/retrieval/process/web` endpoint, allowing an attacker to overwrite a victim's knowledge base with attacker-controlled content.","title":"Open WebUI Knowledge Base Destruction and RAG Poisoning via Unauthorized Collection Overwrite","url":"https://feed.craftedsignal.io/briefs/2024-01-18-open-webui-rag-poisoning/"},{"_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 (\u003c= 0.8.12)","version":"https://jsonfeed.org/version/1.1"}