open-webui-enable-code-execution-bypass

Open WebUI: Jupyter executes code even when ENABLE_CODE_EXECUTION=false, major information security risk

What happened

Here’s the weird bit, up front: Open WebUI’s API endpoint /api/v1/utils/code/execute runs arbitrary Python via Jupyter for any verified user, even when the admin has explicitly set ENABLE_CODE_EXECUTION=false. The issue is tracked as CVE-2026-45672 and the advisory says the feature gate is not enforced on that API route, so the configuration says “disabled” but code still executes.

Open WebUI is a self-hosted AI platform. The CVE entry states the bug affects releases prior to 0.8.12 and that the problem is fixed in 0.8.12. Who discovered it, and the precise disclosure timeline, have not been provided in the information supplied here.

What was confirmed: any verified user can trigger Jupyter execution through that API endpoint when running a vulnerable Open WebUI build. The technical result is arbitrary Python running inside the application process, which can be used to read files, run commands, or move to other parts of the host environment depending on how the instance is deployed and what privileges the service account has.

Why this matters to businesses

If you run Open WebUI in your environment, this is directly relevant. Self-hosted AI stacks often hold sensitive prompts, connectors to internal data stores, and cached files, so a vulnerability that runs arbitrary code is not abstract, it’s operationally painful.

Consequences include data exposure, regulatory attention, customer contract breaches, costly incident response and possible downtime while you rebuild or re-image hosts. Given that many teams treat configuration flags as optional security controls, this one bites hard when a “disabled” setting is actually ineffective.

Open WebUI deployments used by partners, development teams or internal research groups can all become supply-chain like weak points if left unpatched.

If you’ve got the same weakness, here’s what happens next

First, an attacker with a verified account runs code and inspects the environment. They can steal API keys, read mounted volumes, or spawn a reverse shell if the runtime allows outbound connections.

Next, they pivot. If the Open WebUI service account has broad filesystem or network privileges, attackers will try to move laterally to databases, object stores or internal APIs. Persistence is easy if credentials or tokens are accessible.

Finally, recovery costs spiral. You’ll spend leadership time on crisis calls, forensic work to prove what was accessed, legal advice on disclosure, and possibly long rebuild windows for affected hosts.

What to do on Monday morning

Do these actions first, in this order.

• Inventory: find every Open WebUI instance, note version numbers and who owns them.
• Patch or isolate: upgrade affected instances to 0.8.12 or take the service offline until patched.
• Hunt for misuse: check logs for calls to /api/v1/utils/code/execute, abnormal Jupyter sessions, or unusual process spawns.
• Rotate secrets: replace API keys, service tokens and any credentials that the instance could read.
• Lock service accounts: reduce filesystem and network privileges for the Open WebUI process, and remove access to sensitive mounts.
• Review onboarding: restrict who becomes a “verified user”, audit invite flows and remove unused accounts.
• Test restores and response: rehearse rebuilding a compromised Open WebUI host from clean images, including secret injection and configuration checks.

Where ISO standards fit, without the sales pitch

An ISO-aligned approach makes this less likely and faster to fix. Configuration control, secure deployment checklists and code review reduce the chance an API ignores a feature gate, and a clear supplier or internal service ownership model stops forgotten services drifting out of control. For a practical primer on an information security management system see this ISO 27001 guidance.

When continuity and recovery matter, having a documented and tested business continuity plan shortens outage time and reduces uncertainty, see BCMS guidance for how to tie recovery to roles and runbooks.

For baseline technical controls and certification options that help enforce secure defaults, look at IASME-style baseline controls; they map to tighter privilege rules, logging and change control that would have limited this bug’s blast radius.

Wrapping up

Open WebUI’s ENABLE_CODE_EXECUTION=false bypass is a neat reminder that configuration is not security, and that self-hosted AI is now a piece of infrastructure your board should know about. Patch, inventory and reduce privileges, then treat configuration flags like the security controls they pretend to be.