CVE-2026-34222

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.11, there is a broken access control vulnerability in tool values. This issue has been patched in version 0.8.11.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.11, there is a broken access control vulnerability in tool values. This issue has been patched in version 0.8.11.

Summary

Broken Access Control in Tool Valves

Open WebUI supports function calling through "Tools". Function calling allows an LLM to reliably connect to external tools and interact with external APIs. Exemplary use-cases include connecting to an internal knowledge base, retrieving emails from an exchange server, or retrieving order data from a shop backend.

These interactions often require the LLM to authenticate against backend services using API keys specifically created for a technical (Open WebUI) user.

To simplify configuration and secret handling, Open WebUI implements "Valves" and "UserValves" that allow users and administrators to input dynamic details like API keys or configuration options.

Valves have the following distinction:

• Valves: Configurable by admins only.
• UserValves: Configurable by any user.

The Tool Valves endpoint does not properly restrict read access to the valve. This allows a low privileged user to access all data contained within the valve. In the worst case, this gives a low privileged "Member" user access to sensitive Tool data, such as API keys for third-party systems.

---

Details

1) Broken Access Control in Tool Valves

The following steps can be performed to reproduce the vulnerability.

1. An administrator creates an Open WebUI Tool with a configured Valve.

<img width="1038" height="597" alt="image" src="https://github.com/user-attachments/assets/f79bdde9-18fa-49e4-a6c3-5077731f0815" />

2. The administrator configures the API key within the Tool Valve.

<img width="1039" height="446" alt="image" src="https://github.com/user-attachments/assets/d88d06b9-fc21-45e5-8142-d9f874601f87" />

3. A user with at least "Member" privileges logs into Open WebUI.

The following screenshot shows the user overview of the test instance:

<img width="908" height="354" alt="image" src="https://github.com/user-attachments/assets/40025151-418d-4912-8400-1e1a6e5cd4e4" />

The following screenshot illustrates that the "lowpriv" user doesn't have access to the tool:

<img width="815" height="433" alt="image" src="https://github.com/user-attachments/assets/ec06b07f-9735-4728-9dce-d97d721051b8" />

4. The "lowpriv" user uses their Authorization token to retrieve the API key from the Tool Valve.

In order to do so, the attacker needs to know the Tool ID. However, as this ID is always the same for imported tools, and the tool IDs are concatenated from the tool name, guessing tool IDs is trivial.

<img width="754" height="208" alt="image" src="https://github.com/user-attachments/assets/61c80cac-25c8-4730-8156-90869801389f" />

As seen in the following code snippet, the vulnerability is present because the Tool Valves route does not check if the requesting user has administrative permissions (Line 515).

Source: backend/open_webui/routers/tools.py L513–L531

---

PoC

You can find the detailed PoC steps in the Details section.

To execute the exploit:

1. Login as a verified user and copy the authorization token.
2. Access the configured valve of any existing tool with the following request (please mind the placeholders):

GET /api/v1/tools/id/<tool_id>/valves HTTP/1.1
Host: <your_test_host>
Authorization: Bearer <authorization_token_from_step_1>

---

Impact

This information disclosure vulnerability allows low privileged users to access sensitive values stored in Tool Valves. Anyone using Open WebUI Tools with a configured Valve is affected. In the worst case, exploitation allows an attacker to access third-party systems within the context of the configured Open WebUI technical user.

---

Additional Remarks

Additional remarks regarding the CVSS Vector String:

| Component | Value | Rationale | |-----------|-------|-----------| | AC | L | Due to the requirement of a "Member" account | | C | H | Sensitive…

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.11, there is a broken access control vulnerability in tool values. This issue has been patched in version 0.8.11.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.11, there is a broken access control vulnerability in tool values. This issue has been patched in version 0.8.11.

Summary

Broken Access Control in Tool Valves

Open WebUI supports function calling through "Tools". Function calling allows an LLM to reliably connect to external tools and interact with external APIs. Exemplary use-cases include connecting to an internal knowledge base, retrieving emails from an exchange server, or retrieving order data from a shop backend.

These interactions often require the LLM to authenticate against backend services using API keys specifically created for a technical (Open WebUI) user.

To simplify configuration and secret handling, Open WebUI implements "Valves" and "UserValves" that allow users and administrators to input dynamic details like API keys or configuration options.

Valves have the following distinction:

• Valves: Configurable by admins only.
• UserValves: Configurable by any user.

The Tool Valves endpoint does not properly restrict read access to the valve. This allows a low privileged user to access all data contained within the valve. In the worst case, this gives a low privileged "Member" user access to sensitive Tool data, such as API keys for third-party systems.

---

Details

1) Broken Access Control in Tool Valves

The following steps can be performed to reproduce the vulnerability.

1. An administrator creates an Open WebUI Tool with a configured Valve.

<img width="1038" height="597" alt="image" src="https://github.com/user-attachments/assets/f79bdde9-18fa-49e4-a6c3-5077731f0815" />

2. The administrator configures the API key within the Tool Valve.

<img width="1039" height="446" alt="image" src="https://github.com/user-attachments/assets/d88d06b9-fc21-45e5-8142-d9f874601f87" />

3. A user with at least "Member" privileges logs into Open WebUI.

The following screenshot shows the user overview of the test instance:

<img width="908" height="354" alt="image" src="https://github.com/user-attachments/assets/40025151-418d-4912-8400-1e1a6e5cd4e4" />

The following screenshot illustrates that the "lowpriv" user doesn't have access to the tool:

<img width="815" height="433" alt="image" src="https://github.com/user-attachments/assets/ec06b07f-9735-4728-9dce-d97d721051b8" />

4. The "lowpriv" user uses their Authorization token to retrieve the API key from the Tool Valve.

In order to do so, the attacker needs to know the Tool ID. However, as this ID is always the same for imported tools, and the tool IDs are concatenated from the tool name, guessing tool IDs is trivial.

<img width="754" height="208" alt="image" src="https://github.com/user-attachments/assets/61c80cac-25c8-4730-8156-90869801389f" />

As seen in the following code snippet, the vulnerability is present because the Tool Valves route does not check if the requesting user has administrative permissions (Line 515).

Source: backend/open_webui/routers/tools.py L513–L531

---

PoC

You can find the detailed PoC steps in the Details section.

To execute the exploit:

1. Login as a verified user and copy the authorization token.
2. Access the configured valve of any existing tool with the following request (please mind the placeholders):

GET /api/v1/tools/id/<tool_id>/valves HTTP/1.1
Host: <your_test_host>
Authorization: Bearer <authorization_token_from_step_1>

---

Impact

This information disclosure vulnerability allows low privileged users to access sensitive values stored in Tool Valves. Anyone using Open WebUI Tools with a configured Valve is affected. In the worst case, exploitation allows an attacker to access third-party systems within the context of the configured Open WebUI technical user.

---

Additional Remarks

Additional remarks regarding the CVSS Vector String:

| Component | Value | Rationale | |-----------|-------|-----------| | AC | L | Due to the requirement of a "Member" account | | C | H | Sensitive…

Summary

Broken Access Control in Tool Valves

Open WebUI supports function calling through "Tools". Function calling allows an LLM to reliably connect to external tools and interact with external APIs. Exemplary use-cases include connecting to an internal knowledge base, retrieving emails from an exchange server, or retrieving order data from a shop backend.

These interactions often require the LLM to authenticate against backend services using API keys specifically created for a technical (Open WebUI) user.

To simplify configuration and secret handling, Open WebUI implements "Valves" and "UserValves" that allow users and administrators to input dynamic details like API keys or configuration options.

Valves have the following distinction:

• Valves: Configurable by admins only.
• UserValves: Configurable by any user.

The Tool Valves endpoint does not properly restrict read access to the valve. This allows a low privileged user to access all data contained within the valve. In the worst case, this gives a low privileged "Member" user access to sensitive Tool data, such as API keys for third-party systems.

---

Details

1) Broken Access Control in Tool Valves

The following steps can be performed to reproduce the vulnerability.

1. An administrator creates an Open WebUI Tool with a configured Valve.

<img width="1038" height="597" alt="image" src="https://github.com/user-attachments/assets/f79bdde9-18fa-49e4-a6c3-5077731f0815" />

2. The administrator configures the API key within the Tool Valve.

<img width="1039" height="446" alt="image" src="https://github.com/user-attachments/assets/d88d06b9-fc21-45e5-8142-d9f874601f87" />

3. A user with at least "Member" privileges logs into Open WebUI.

The following screenshot shows the user overview of the test instance:

<img width="908" height="354" alt="image" src="https://github.com/user-attachments/assets/40025151-418d-4912-8400-1e1a6e5cd4e4" />

The following screenshot illustrates that the "lowpriv" user doesn't have access to the tool:

<img width="815" height="433" alt="image" src="https://github.com/user-attachments/assets/ec06b07f-9735-4728-9dce-d97d721051b8" />

4. The "lowpriv" user uses their Authorization token to retrieve the API key from the Tool Valve.

In order to do so, the attacker needs to know the Tool ID. However, as this ID is always the same for imported tools, and the tool IDs are concatenated from the tool name, guessing tool IDs is trivial.

<img width="754" height="208" alt="image" src="https://github.com/user-attachments/assets/61c80cac-25c8-4730-8156-90869801389f" />

As seen in the following code snippet, the vulnerability is present because the Tool Valves route does not check if the requesting user has administrative permissions (Line 515).

Source: backend/open_webui/routers/tools.py L513–L531

---

PoC

You can find the detailed PoC steps in the Details section.

To execute the exploit:

1. Login as a verified user and copy the authorization token.
2. Access the configured valve of any existing tool with the following request (please mind the placeholders):

GET /api/v1/tools/id/<tool_id>/valves HTTP/1.1
Host: <your_test_host>
Authorization: Bearer <authorization_token_from_step_1>

---

Impact

This information disclosure vulnerability allows low privileged users to access sensitive values stored in Tool Valves. Anyone using Open WebUI Tools with a configured Valve is affected. In the worst case, exploitation allows an attacker to access third-party systems within the context of the configured Open WebUI technical user.

---

Additional Remarks

Additional remarks regarding the CVSS Vector String:

| Component | Value | Rationale | |-----------|-------|-----------| | AC | L | Due to the requirement of a "Member" account | | C | H | Sensitive…