By A critical flaw in Open WebUI lets any authenticated user execute arbitrary Python code on your server — even when you’ve explicitly disabled code execution. CVE-2026-45672 scores 9.8 on the CVSS scale and affects every Open WebUI installation below version 0.8.12. If you’re running it in multi-user mode on anything older, assume your Jupyter backend is open to anyone with a login.
The Flaw: UI Toggle, No API Enforcement
Open WebUI has an environment variable, ENABLE_CODE_EXECUTION, that is supposed to control whether users can run Python code in the chat interface. Set it to false and the “Run Code” button disappears from the UI. Admins running team deployments set this thinking they’ve locked code execution down to privileged users only.
They haven’t. The actual execution endpoint — POST /api/v1/utils/code/execute — never checks that config value. Any authenticated user can POST a Python payload directly to the endpoint and the Jupyter backend will execute it and return the output. The config is a UI-layer decision with no enforcement at the API layer.
POST /api/v1/utils/code/execute
Authorization: Bearer <valid_user_token>
Content-Type: application/json
{"code": "import os; print(os.environ)"}That request works on any vulnerable instance regardless of what ENABLE_CODE_EXECUTION is set to. The response is a full environment dump — every secret, every credential your Open WebUI instance has access to.
What You’re Actually Handing Over
Arbitrary Python execution in a Jupyter container sounds contained. It isn’t. The Jupyter container has network access to internal services, making this simultaneously an RCE and a server-side request forgery (SSRF) vector. An attacker with a valid session can read environment variables — including API keys, database credentials, or any secrets your Open WebUI instance can reach — enumerate internal services, and potentially pivot further depending on your container configuration.
The entry bar is trivially low: a valid user account and a single HTTP POST. No admin rights required. No memory corruption or crypto attack. This is a missing authorization check — the most preventable class of vulnerability.
Who Is Actually Exposed
Not every Open WebUI deployment is at equal risk. Single-user instances running on localhost with no outside access are essentially safe from this specific CVE. Everyone else should take this seriously:
- Company-internal AI portals — teams that deployed Open WebUI as a shared LLM interface and trust that “internal users are safe”
- RBAC deployments with code execution disabled for non-admins — the entire point of that config was to restrict this capability; it didn’t
- Any instance exposed beyond localhost via reverse proxy, Tailscale, ngrok, or a VPN endpoint
Open WebUI has 128,000+ GitHub stars and is one of the most widely deployed self-hosted AI interfaces. A lot of teams are running it in exactly these configurations.
The Fix and the Pattern
The patch in 0.8.12 adds a single guard to backend/open_webui/routers/utils.py: the handler now checks request.app.state.config.ENABLE_CODE_EXECUTION before dispatching to Jupyter and returns HTTP 403 with FEATURE_DISABLED('Code execution') when the flag is false. One check. The kind that should have shipped with the feature on day one.
This is the third CVE in Open WebUI’s code execution path in two years. CVE-2025-64496 allowed account takeover that escalated to code execution. CVE-2026-0765 was a command injection in the package install flow. Now CVE-2026-45672 is a feature gate that never gated anything. The pattern is consistent: code execution features ship, authorization enforcement lags. If you’re running Open WebUI, its CVE history should inform your trust model.
What to Do Right Now
Upgrade to 0.8.12. That’s the fix. Check the release page for the upgrade path. If you can’t upgrade immediately, block the vulnerable endpoint at your reverse proxy:
# Nginx interim mitigation
location = /api/v1/utils/code/execute {
deny all;
return 403;
}Beyond patching: restrict Open WebUI access to trusted network segments, audit your authenticated user list, and review your container’s network exposure. Open WebUI’s hardening documentation covers these steps in detail.
The broader point: AI frontends are infrastructure now. Open WebUI, LibreChat, AnythingLLM — these run in enterprise environments with access to production API keys and internal services. They deserve the same security scrutiny as any other server-side application. A config flag is not a security control until the code actually checks it.
