Open WebUI Jupyter Code Execution Bypass Vulnerability

A newly disclosed vulnerability in the highly popular Open WebUI platform underscores the silent dangers of decoupled security controls. Tracked under the advisory GHSA-482j-2pq6-q5w4, this critical security flaw reveals that the built-in Jupyter code execution engine can be manipulated by any verified user, explicitly bypassing administrative safeguards.

Discovered and reported by security researcher Highdoge-woof, this vulnerability affects Open WebUI versions up to and including 0.8.11. For enterprise environments and homelab enthusiasts relying on Open WebUI to interface with Large Language Models (LLMs).

This flaw transforms a seemingly locked-down application into a vector for Arbitrary Code Execution (ACE) and Server-Side Request Forgery (SSRF).

Open WebUI has emerged as a premier, feature-rich graphical interface for interacting with local and remote LLMs. To provide advanced capabilities akin to OpenAI’s Advanced Data Analysis, Open WebUI integrates with a Jupyter backend.

This integration allows the AI models to write, execute, and analyze Python code dynamically, offering users powerful data manipulation and programmatic problem-solving tools directly within the chat interface.

Naturally, exposing a Python execution environment presents immense security risks. To mitigate this, Open WebUI provides administrators with a strict configuration toggle: ENABLE_CODE_EXECUTION. When set to false, the platform is designed to restrict all code execution capabilities.

Administrators operating in zero-trust or highly sensitive environments heavily rely on this boolean flag to ensure their containerized deployments remain completely isolated from arbitrary user scripts. However, the discovery of GHSA-482j-2pq6-q5w4 highlights a critical gap between frontend configuration visibility and backend API enforcement.

Open WebUI Vulnerability

The core of this vulnerability lies in an architectural disconnect within the backend routing logic. While the administrative dashboard correctly reflects the ENABLE_CODE_EXECUTION: false state, the specific backend endpoint responsible for handling the code execution requests /api/v1/utils/code/execute fails to validate this configuration flag before processing incoming payloads.

When an authenticated user interacts with the application, they are issued a Bearer token for session validation. An attacker with a valid low-privileged account can entirely bypass the frontend UI restrictions and directly communicate with the backend REST API.

By crafting a malicious HTTP POST request, the attacker can submit arbitrary Python code. Because the router fails to check request.app.state.config.ENABLE_CODE_EXECUTION, the backend blindly forwards the payload to the attached Jupyter execution engine.

The proof of concept provided by the security researcher elegantly demonstrates the simplicity and severity of this bypass. In a verified test environment running Open WebUI v0.8.11 within Docker.

An attacker first queries the configuration endpoint to confirm that the administrator has disabled code execution. The system responds affirmatively, showing "ENABLE_CODE_EXECUTION": false.

Despite this, the attacker initiates a direct POST request to the execution endpoint:

curl -s -X POST http://target:8080/api/v1/utils/code/execute \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"code":"import os; print(os.popen(\"id\").read())"}'

The backend processes the request, returning a 200 OK status and the standard output of the executed command. In the researcher’s demonstration, the PoC successfully read an internal secret (OPEN-WEBUI-SSRF-SECRET), definitively proving that the configuration gate was bypassed.

The implications of this vulnerability extend far beyond simply running unauthorized scripts. The true danger lies in the network positioning of the Jupyter container within typical deployment architectures.

Arbitrary Code Execution (ACE): An attacker can spawn processes, read sensitive system files, and manipulate the internal state of the Jupyter container.
Server-Side Request Forgery (SSRF): Because the Jupyter container is typically deployed within the same Docker network as the Open WebUI backend, internal databases, and potentially other microservices, it acts as a highly privileged pivot point. An attacker can use the compromised Jupyter container to scan internal subnets, access unauthenticated internal APIs, and execute requests that appear to originate from a trusted internal source.
Data Exfiltration: Threat actors can write Python scripts designed to systematically scrape internal network resources, packaging sensitive data and exfiltrating it to external command-and-control servers.
The Illusion of Security: Perhaps the most insidious aspect of GHSA-482j-2pq6-q5w4 is the false sense of security it creates. System administrators auditing their configurations would see the code execution feature explicitly disabled, leading them to believe their threat surface was minimized, all while the backdoor remained wide open to any verified user.

Remediation and Patch

The maintainers of O p en WebUI responded to the disclosure by implementing a robust fix in commit 6d736d3c5, which was subsequently bundled into the v0.8.12 release.

A review of the patch applied to backend/open_webui/routers/utils.py reveals the missing enforcement logic. The /api/v1/utils/code/execute handler was explicitly updated to query the application’s configuration state before establishing any connection with the Jupyter engine.

If request.app.state.config.ENABLE_CODE_EXECUTION is evaluated as false, the API now aggressively terminates the request, returning an HTTP 403 Forbidden status paired with a FEATURE_DISABLED('Code execution') exception.

Furthermore, the development team audited and secured the retrieval-side code paths within the same commit to ensure no alternative execution vectors remained exposed.

Organizations utilizing Open WebUI must immediately audit their deployed versions. If your deployment is running 0.8.11 or older, it should be treated as vulnerable, regardless of your UI configuration settings.

Upgrade Immediately: Pull the latest Docker images and update the open-webui pip package to version 0.8.12 or higher.
Audit Logs: Review internal access logs for the /api/v1/utils/code/execute endpoint, specifically looking for POST requests originating from unexpected users or occurring during timeframes when the feature was supposedly disabled.
Network Segmentation: As a defense-in-depth measure, ensure that any code execution containers (like Jupyter) are subjected to strict egress filtering. They should only be able to communicate with explicitly required services, mitigating the risk of SSRF and data exfiltration even if code execution is achieved.