Open WebUI: code execution endpoint runs arbitrary Python even when ENABLE_CODE_EXECUTION is false

Impact

Any verified Open WebUI user can run arbitrary Python through the Jupyter execution path by calling the API endpoint directly. Turning the feature off in the admin settings does not block it: the setting says disabled, but the endpoint never checks it. The code runs with the access of the Jupyter kernel behind the deployment, so the attacker can read whatever that kernel can see (mounted model storage, credentials in its environment, internal services it can reach). On a shared inference fleet, every account on the chat front end becomes a code-execution foothold, including accounts the admin believed could only chat.

Who can reach it

Any authenticated, verified user of the Open WebUI instance, over the network to its HTTP API. No admin rights needed. Instances with open self-registration widen this to anyone who can sign up.

What to do

Upgrade Open WebUI to 0.8.12 or later and restart the container or service. Until then, do not rely on ENABLE_CODE_EXECUTION=false. Disconnect or isolate the Jupyter backend, restrict who can register and get verified, and limit what the Jupyter kernel can reach on the network.

References

Related entries

• ChromaDB (SimpleRBAC): Authorization provider evaluates permissions incorrectlyCVE-2026-45831 · ChromaDB (SimpleRBAC)High
• ChromaDB (V1 endpoints): Tenant/database passed as `None` to the authz layerCVE-2026-45832 · ChromaDB (V1 endpoints)High
• ChromaDB: Authenticated code injectionCVE-2026-45833 · ChromaDBHigh
• LiteLLM (key generation): internal_user can mint keys with routes their role forbidsCVE-2026-47101 · LiteLLM (key generation)High
• LiteLLM (`/user/update`): User can self-elevate `user_role`CVE-2026-47102 · LiteLLM (`/user/update`)High
• vLLM (hardcoded `trust_remote_code=True`): Two model implementation files force remote code execution regardlessCVE-2026-4944 · vLLM (hardcoded `trust_remote_code=True`)High