CVE-2026-45395 - Open WebUI tool update authorization RCE

Open WebUI versions before 0.9.5 did not apply the same workspace.tools permission check to tool updates that they applied to tool creation. A user with a write grant on an existing tool, but without the trusted workspace.tools permission, could replace the server-side Python tool content and reach the code execution path that should be reserved for trusted tool authors.

This is a trust-boundary bug, not a generic “exec is unsafe” finding. Open WebUI tools are intentionally powerful, so the mergeable fix is to make update, create, import, sharing, and execution semantics line up: ordinary write access must not silently become permission to run code on the Open WebUI host.

When to use it

Use this recipe when a repository or Open WebUI deployment lets users create, edit, or update server-side tools. It is aimed at source-code remediation, trusted tool-authorship review, workspace permission hardening, and audit evidence that ordinary write grants cannot become Python tool code execution.

Inputs

  • Open WebUI version, workspace permission model, tool create/update routes, trusted tool author policy, and deployment exposure.
  • Source paths for tool update handlers, workspace.tools checks, tool persistence, Python execution, audit logs, and permission tests.
  • Regression fixtures for trusted tool authors, ordinary write users, cross-workspace users, update-vs-create parity, and denied tool-content replacement.
  • Boundary evidence: existing tools, modified tool history, server-side code execution permissions, logs, impacted workspaces, and cleanup owner.

Affected versions

  • Vulnerable: open-webui <0.9.5
  • Fixed: open-webui 0.9.5+
  • Affected endpoint: POST /api/v1/tools/id/{id}/update
  • Affected pattern: a tool update path checks ownership or write grant but does not also require the code-execution permission boundary workspace.tools.
  • Sensitive sink: server-side Python tool loading and execution.

Indicator-of-exposure

  • The repository deploys, builds, vendors, or documents Open WebUI <0.9.5.
  • Tool creation, update, import, sharing, or access-grant features are enabled.
  • Non-admin users can receive write grants to tools created by trusted users.
  • workspace.tools is disabled for some users because they are not trusted to execute server-side code.
  • Open WebUI runs with model provider keys, uploaded files, chat history, workspace data, cloud credentials, internal network access, or broad writable container storage.

Quick checks:

rg -n "open-webui|OPEN_WEBUI|workspace\.tools|tools.py|/api/v1/tools|Tools.get_tool_by_id|AccessGrants.has_access|load_tool_module_by_id|USER_PERMISSIONS|ToolForm" .
python -m pip show open-webui
pip freeze | rg -i "^open-webui=="
docker images | rg -i "open-webui"

Windows:

rg -n "open-webui|OPEN_WEBUI|workspace\.tools|tools.py|/api/v1/tools|Tools.get_tool_by_id|AccessGrants.has_access|load_tool_module_by_id|USER_PERMISSIONS|ToolForm" .
python -m pip show open-webui
python -m pip freeze | rg -i "^open-webui=="
docker images | rg -i "open-webui"

Do not create malicious tools, run tool payloads, or print container environment variables during triage.

Remediation strategy

  • Upgrade Open WebUI to 0.9.5+ everywhere this repository controls package pins, Docker tags, Helm charts, compose files, SBOMs, or deployment docs.
  • Require workspace.tools or administrator authorization for any operation that can save, import, update, test, or execute server-side tool code.
  • Keep ordinary write grants scoped to collaboration metadata unless the user also has the explicit code-execution permission.
  • Add regression tests that prove a user with tool write access but without workspace.tools cannot update tool content or trigger tool loading.
  • Review tool access grants and rotate Open WebUI/provider/runtime credentials if untrusted users could update tools during the exposure window.

The prompt

You are remediating CVE-2026-45395 / GHSA-p4fx-23fq-jfg6, the Open WebUI tool
update authorization bypass that lets a write grant reach server-side Python
tool execution without `workspace.tools`. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Open WebUI, aligns tool
  update authorization with the `workspace.tools` trust boundary, adds safe
  regression tests, refreshes generated artifacts, and documents operator
  cleanup, or
- TRIAGE.md if this repository does not own an affected Open WebUI deployment
  or cannot make a safe change.

## Rules

- Scope only CVE-2026-45395 / GHSA-p4fx-23fq-jfg6 and directly related Open
  WebUI tool authorization boundaries.
- Treat Open WebUI session cookies, user tokens, model provider keys, uploaded
  files, chat history, tool source, workspace data, database contents, runtime
  environment variables, and logs as sensitive.
- Do not create malicious tools, execute tool payloads, run shell commands
  through Open WebUI, beacon to external services, dump `/etc/passwd`, or print
  secrets to prove exposure.
- Do not preserve a path where ordinary tool `write` grants imply server-side
  code execution.
- Do not auto-merge.

## Steps

1. Inventory every Open WebUI runtime controlled by this repository:
   dependency pins, lockfiles, Dockerfiles, image tags, compose files, Helm
   charts, Kubernetes manifests, Terraform, environment templates, runbooks,
   SBOMs, seed users, seeded tools, and generated deployment docs.
2. Determine every resolved Open WebUI version. A target is vulnerable if it
   resolves to `<0.9.5`.
3. Search for tool authorization surfaces:
   - create, update, import, export, share, access-grant, and execution routes;
   - `workspace.tools`, `workspace.tools_import`, admin checks, and default user
     permissions;
   - ownership checks and `AccessGrants.has_access` for tools;
   - tool loading paths such as `load_tool_module_by_id` or equivalent code
     execution sinks.
4. If this repository does not deploy Open WebUI or only contains client code,
   stop with `TRIAGE.md` listing files checked, runtime owner, and required
   fixed version `open-webui 0.9.5+`.
5. Upgrade all controlled Open WebUI packages and images to `0.9.5+`.
   Regenerate lockfiles, image digests, deployment render output, SBOMs, and
   dependency reports.
6. Where this repository controls Open WebUI product code or local patches,
   enforce the code-execution permission boundary on tool updates:
   - require admin or `workspace.tools` before accepting tool content changes;
   - keep `write` grants insufficient for code content updates unless combined
     with the explicit tool execution permission;
   - apply the same boundary to imports, duplicated tools, API updates, and
     background sync paths;
   - fail closed when role or permission context is unavailable.
7. Add safe regression tests:
   - a user without `workspace.tools` cannot create a tool;
   - a user with only a tool `write` grant cannot update executable tool
     content;
   - the denied update path does not call the tool loader;
   - an admin or trusted tool author can still update through the intended
     path;
   - logs and test output omit tokens, tool secrets, prompts, and environment
     values.
8. Add deployment containment for non-atomic rollouts:
   - temporarily disable tool update/import routes for non-admin users;
   - remove broad tool write grants from untrusted users;
   - isolate Open WebUI from cloud metadata, Docker socket, host mounts, and
     unnecessary egress;
   - keep the containment until every runtime is patched.
9. Add a PR body section named `CVE-2026-45395 operator actions` that states:
   - Open WebUI versions before and after;
   - whether `workspace.tools` is enabled and for which roles;
   - whether users had tool write grants without code-execution trust;
   - whether any tools were updated by untrusted users during the exposure
     window;
   - which Open WebUI, model provider, runtime, and workspace credentials should
     be rotated;
   - which audit, application, gateway, and process logs should be reviewed.
10. Run relevant validation: dependency install, lockfile integrity, unit/API
    authorization tests, route tests, deployment render, container build, SBOM
    refresh, and dependency/security scans available in this repository.
11. Use PR title:
    `fix(sec): remediate CVE-2026-45395 in Open WebUI tools`.

## Stop conditions

- No affected Open WebUI runtime is controlled by this repository.
- A fixed Open WebUI version cannot be consumed without a broader migration.
- Product requirements intentionally grant ordinary tool editors server-side
  code execution; document the risk and require a product/security decision.
- Meaningful verification would require executing malicious tool content or
  exposing secrets.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Open WebUI, requires workspace.tools for updates, adds negative permission tests, and documents review/cleanup for modified tools.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, trusted-tool boundary, impacted workspaces, required fix, and residual risk.
  • The output must include exact validation commands and must not execute untrusted tools, print workspace secrets, or expose production tool code/logs.

Verification - what the reviewer looks for

  • No controlled package, image, deployment target, SBOM, or generated dependency report resolves Open WebUI <0.9.5.
  • Tool update, import, and executable-content paths require admin or workspace.tools, not just ownership or write grant.
  • Regression tests prove a write-only collaborator cannot reach the tool loader.
  • Operator notes cover access-grant review, log review, and credential rotation when exposure was possible.
  • No exploit code, tool payloads, secrets, or environment dumps are committed.

Watch for

  • Upgrading the main image while worker, sidecar, Helm, or compose references still run an older Open WebUI tag.
  • Fixing the UI but leaving API, import, duplicate, or background sync paths able to update executable tool content.
  • Treating tool write grants like normal document collaboration when the target resource is executable Python.
  • Logging tool source, provider keys, session cookies, prompts, or environment values while adding tests.
  • Disabling workspace.tools globally without reviewing existing tool access grants and prior tool update activity.

References