CVE-2026-0766
| CVE ID | CVE-2026-0766 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2026-01-23 |
| Issuing CNA | Zero Day Initiative (ZDI-26-032) |
| Claimed Severity | High (CVSS 8.8, CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) |
Timeline
This CVE is formally disputed. The issuing CNA has reviewed Open WebUI's analysis and agreed the record should be annotated as disputed/rejected, but the record has not yet been amended, so the dispute remains open through the CVE Program's process. The assessment below is Open WebUI's position in the meantime.
| Date | Event |
|---|---|
| 2025-10 | ZDI submits the underlying report through Open WebUI's security channel. Open WebUI closes it as out of scope and not a vulnerability under its published security policy, but does so without giving the reporter a written explanation at the time, which was a mistake on Open WebUI's part. |
| 2026-01-23 | ZDI publishes the CVE (ZDI-26-032). |
| 2026-05-04 | Open WebUI files a formal dispute with the CVE Program and notifies ZDI directly. Neither ZDI nor the CVE Program responds. |
| 2026-06-15 | Open WebUI files another dispute with the CVE Program; the Secretariat directs it to the issuing CNA (ZDI), which owns the record. The request is subsequently closed. |
| 2026-07-02 | With the CNA non-responsive, Open WebUI escalates the dispute a third time, to the CVE Program's Root / Top-Level Root under the CVE Record Dispute Policy (v2.0.0). |
| 2026-07-06 | Under the CVE Program's record-dispute procedure, the Program forwards the dispute to the issuing CNA (ZDI) for its determination. |
| 2026-07-08 | ZDI reviews Open WebUI's analysis and agrees with its disposition on this finding, and agrees to note the CVE as disputed/rejected with a reference to this page. |
| 2026-07-15 | Open WebUI follows up. The record still shows as PUBLISHED with no annotation. |
| 2026-07-21 | Open WebUI follows up again and asks the CVE Program to help bring the record to closure. ZDI replies the same day that it will respond and coordinate the record update later that week. |
| 2026-08-03 | Open WebUI follows up again. The record is unchanged. |
| 2026-08-08 | With no further movement from ZDI for over a month, Open WebUI returns to the CVE Program Root and asks it for closure. |
| 2026-08-14 | With no response to that request either, Open WebUI files a fresh request with the CVE Program for this record, asking it to carry out the update the CNA has already agreed to rather than reopening the dispute itself. |
As of 2026-08-14, the issuing CNA has agreed that the record should be annotated as disputed/rejected, but the CVE record still shows as PUBLISHED and has not been amended. The substantive dispute is therefore settled, and what remains outstanding is the record update itself, which Open WebUI has now asked the CVE Program to carry out. This disposition stands as Open WebUI's official assessment.
What the CVE Claims
The function load_tool_module_by_id in backend/open_webui/utils/plugin.py allegedly allows a low-privileged authenticated remote attacker to execute arbitrary Python code by submitting a Tool whose source contains arbitrary Python, which the function then passes to exec().
Why This Is Not a Vulnerability
A user with the tools permission opens the workspace, writes Python into a Tool and saves it. From that point the server runs that code whenever the Tool is used, which is what the person who saved it asked it to do, and what the screen offers when it invites them to write one. There is nothing to validate in the submission, because the submission is the program the user asked to have run. The record describes a user with permission to run code on the server running code on the server.
This mirrors the design of every other code-extension system: Jupyter runs notebook cells, n8n runs Code nodes, Home Assistant runs the scripts an operator drops into it.
Access Control
The routes that invoke load_tool_module_by_id are gated by user.role == 'admin' or by the workspace.tools permission, which is disabled by default. Granting workspace.tools is documented as equivalent to giving the user shell access to the server. There is no path by which an unprivileged user can reach this function.
Severity
Because this is intended behavior and not a vulnerability, no CVSS score applies to it; the published 8.8 (High) scores the software's designed ability to load and execute user-authored Tool code. Separately, and only if the record is scored at all, the vector's PR:L (privileges required, low) is inaccurate: the routes that reach this function require an administrator or the root-equivalent workspace.tools permission, which is PR:H. This is recorded for completeness and does not bear on the disposition, which is out of scope on the intended-behavior basis regardless of severity.
Applicable Security Policy Rules
- Rule 10: The Tools feature is designed to execute user-provided Python code on the server. Reports involving Tools or Functions are closed as intended behavior.
- Rule 9: "Pasting untrusted code into Functions/Tools" is explicitly cited as out-of-scope.
- Rule 1: Expected protocol behavior is not a vulnerability.
Impact to Users
No action required. This CVE describes intended functionality. Tools execute Python code on the server by design. If you have granted workspace.tools to untrusted users, review the Plugin Security documentation.