Skip to content

Open WebUI's chat completion API allows tool restrictions to be bypassed

High severity GitHub Reviewed Published May 9, 2026 in open-webui/open-webui • Updated May 14, 2026

Package

pip open-webui (pip)

Affected versions

<= 0.8.5

Patched versions

0.8.6

Description

Summary

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.

Details

In the chat_completion API, the parameters tool_ids and tool_servers are supplied by the user. These parameters are used to create a tools_dict by the middleware. This is then used by get_tool_by_id to retrieve the appropriate tool. However, there is no checks in that ensures the user that uses the API has permission to use the tool, meaning that a user can invoke any server tool by supplying the correct tool_id or tool_servers parameters via the chat completion API. Moreover, the authentication token stored in the server would be used when invoking the tool, so the tool will be invoked with the server privilege.

PoC

To reproduce the issue, create an admin user and create an external tool via the admin settings. Set the type to "MCP Streamable HTTP" for the tool, and the url pointing to a mcp server. For example, the public instance of the "Fetch" mcp server can be used, which is located at "https://remote.mcpservers.org/fetch/mcp". Other mcp servers, e.g. the GitHub MCP server can also be used. Then set the "Auth" field appropriately. (Fetch mcp does not require Auth to be set).

Set the ID, name and description for the MCP server and set visibility to private. This should prevent any user from using the mcp server. (For the example below, we use the fetch mcp server and set the ID to 1)

Next create a user with low privilege and enable API keys from the admin settings.

Then use the chat completion API with the low privilege user with a prompt specifying the use of the restricted tool, and include the id of the tool in the tool_ids parameter. For example, to use the fetch mcp server set up before:

def chat_with_model(token):
    url = 'http://localhost:3000/api/chat/completions'
    headers = {
        'Authorization': f'Bearer {token}',
        'Content-Type': 'application/json'
    }
    data = {
      "model": "llama3.1:latest",
      "messages": [
        {
          "role": "user",
          "content": "Use the fetch tool to fetch content of the url https://raw.githubusercontent.com/modelcontextprotocol/servers/refs/heads/main/src/fetch/LICENSE"
        }],
        
        "tool_ids" : [
            "server:mcp:1",
        ],
    }
    response = requests.post(url, headers=headers, json=data)
    return response.json()

Note that the tool will be used to fetch the content of the file, despite the tool is restricted and has it's visibility set to private

Impact

This issue may lead to restricted tools being invoked by users via the chat completion API

Resolution

Fixed across two releases

  • Local Tool records (tool_ids: ["<tool_id>"] referencing a stored Tool): fixed in commit 9b06fdc8f, first released in v0.7.0. get_tools() in backend/open_webui/utils/tools.py (line 166) now resolves the caller's group memberships and rejects each requested tool_id whose owner isn't the caller and for which no AccessGrants.has_access(resource_type='tool', permission='read') grant exists. Admins continue to bypass when BYPASS_ADMIN_ACCESS_CONTROL is enabled (its documented UI/posture purpose).

  • Admin-configured MCP servers (tool_ids: ["server:mcp:<id>"], the report's exact PoC): fixed in commit 4737e1f11, first released in v0.8.6. The MCP-resolution loop in backend/open_webui/utils/middleware.py (line 2670) now calls has_connection_access(user, mcp_server_connection) and skips the server with a warning if the user has no grant — the server's stored credentials are never used on behalf of an unauthorized caller.

Users on >= 0.8.6 are not affected.

References

@doge-woof doge-woof published to open-webui/open-webui May 9, 2026
Published to the GitHub Advisory Database May 14, 2026
Reviewed May 14, 2026
Last updated May 14, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(17th percentile)

Weaknesses

Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action. Learn more on MITRE.

CVE ID

CVE-2026-45350

GHSA ID

GHSA-4pcg-253r-rf9w

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.