Open-Webui — CraftedSignal Threat Feed

Open WebUI LDAP Empty Password Authentication Bypass

hello@craftedsignal.io — Fri, 08 May 2026 19:38:31 +0000

Open 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 LdapForm Pydantic model accepts an empty string for the password field without any minimum length constraint. Subsequently, the Connection.bind() 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 6fdd19bf1) 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.

Attack Chain

LDAP authentication is enabled on the Open WebUI instance (ENABLE_LDAP=True).
The attacker identifies a valid LDAP username.
The underlying LDAP server accepts unauthenticated simple binds (OpenLDAP default, some AD configs).
Attacker sends a POST request to /api/v1/auths/ldap with the target username and an empty password.
The application’s DN bind succeeds, finding the target user via LDAP search.
The application attempts a user bind using the provided (empty) password.
The LDAP server returns success for the unauthenticated bind due to the empty password.
authenticate_user_by_email issues a full session token for the target user, granting complete account access.

Impact

Successful 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.

Recommendation

Apply the mitigations recommended in GHSA-2r4p-jpmg-48f4 to prevent empty passwords from being used in LDAP authentication.
Deploy the Sigma rule “Detect Open WebUI LDAP Authentication Bypass Attempt” to monitor for POST requests to the /api/v1/auths/ldap endpoint with an empty password field, indicating a potential exploit attempt.
Ensure the LDAP server is configured to reject unauthenticated simple binds with empty passwords.
Monitor web server logs for POST requests to /api/v1/auths/ldap (webserver log source) and correlate with other authentication-related events.

Open WebUI Cross-Instance Cache Poisoning Vulnerability

hello@craftedsignal.io — Thu, 09 May 2024 12:00:00 +0000

Open 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 REDIS_KEY_PREFIX usage for the tool_servers and terminal_servers keys in utils/tools.py. 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 6fdd19bf1) 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 REDIS_KEY_PREFIX aims to provide, potentially impacting blue-green deployments, multi-region setups, and cluster topologies.

Attack Chain

An 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.
The attacker configures a malicious tool server on Instance A, pointing to https://attacker-controlled.example.com/openapi.json. This configuration triggers a write to the tool_servers Redis key without the REDIS_KEY_PREFIX (line 841 in utils/tools.py).
Users on Open WebUI Instance B attempt to query available tools. This action triggers a read from the same unprefixed tool_servers Redis key (line 850 in utils/tools.py).
Instance B retrieves the attacker’s poisoned tool server list from Instance A, which now includes the attacker’s server, possibly replacing legitimate tool servers.
A 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.
The attacker’s server responds with arbitrary tool outputs, which are then fed back into Instance B’s LLM context.
The malicious tool output is treated as trusted data within Instance B’s LLM, enabling prompt injection and misinformation delivery.
The attacker leverages prompt injection and misinformation delivery to further compromise Instance B and exfiltrate sensitive data.

Impact

Successful exploitation of this vulnerability leads to cross-instance cache poisoning, where one instance’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’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’s silent failure mode makes detection difficult for victim instances.

Recommendation

Deploy the Sigma rule “Detect Open WebUI Tool Server Configuration Change” to monitor for unauthorized changes to the tool_servers key (rule below).
Deploy the Sigma rule “Detect Open WebUI Terminal Server Configuration Change” to monitor for unauthorized changes to the terminal_servers key (rule below).
Apply available patches or upgrades to Open WebUI to versions beyond 0.8.12 as soon as they are released to address CVE-2026-44552.
Restrict admin access to Open WebUI instances and enforce strong password policies.
Review and audit existing Open WebUI deployments to ensure proper configuration and security best practices.

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.