CVE-2026-77934: Coze Studio RCE Vulnerability

CVE-2026-77934 Overview

Coze Studio versions before 0.5.0 ship with an insecure default configuration that exposes the workflow code runner to any authenticated user. The CODE_RUNNER_TYPE environment variable defaults to local, which executes workflow Python nodes directly in an unsandboxed python3 subprocess on the host. Attackers bypass the regex-based import filter using __import__('subprocess') to execute arbitrary operating system commands. Successful exploitation allows theft of environment variables, model API keys, and direct access to the backing MySQL, MinIO, Redis, and etcd services. The weakness is classified under CWE-1188: Insecure Default Initialization of Resource.

Critical Impact

Any registered Coze Studio user can achieve remote code execution on the host, exfiltrate secrets, and pivot to the full backend data plane.

Affected Products

• Coze Studio versions prior to 0.5.0
• Deployments using the default CODE_RUNNER_TYPE="local" configuration
• Docker-based Coze Studio installations following the shipped .env.example

Discovery Timeline

• 2026-10-20 - CVE-2026-77934 published to NVD
• 2026-10-20 - Last updated in NVD database

Technical Details for CVE-2026-77934

Vulnerability Analysis

Coze Studio allows users to build AI workflows that include Python code nodes. In vulnerable versions, these nodes execute inside a local Python interpreter on the Coze Studio host rather than inside the intended deno + pyodide sandbox. The product enforces a regex-based import blocklist to restrict dangerous modules, but this filter inspects only literal import statements. Attackers invoke Python's built-in __import__ function to load subprocess, os, or any other module without matching the filter. Once loaded, the attacker executes arbitrary shell commands under the privileges of the Coze Studio service account.

Because the code runs on the application host, it inherits access to every service credential the container holds. Observed impact includes exfiltration of model provider API keys, cloud credentials, and direct network reachability to backend MySQL, MinIO object storage, Redis, and etcd.

Root Cause

The root cause is an insecure default in docker/.env.example that sets CODE_RUNNER_TYPE="local". The local runner uses a Python virtual environment with no isolation from the host process, filesystem, or network. The maintainers acknowledged this in commit fcf40d1, which switches the default runner to sandbox. Reliance on a regex import filter rather than a true execution sandbox compounds the issue, since Python offers multiple module-loading primitives that bypass textual pattern matching.

Attack Vector

An authenticated low-privilege user creates or edits a workflow containing a Python code node. The node payload invokes __import__('subprocess') to obtain a reference to subprocess without triggering the import blocklist. The attacker then runs commands such as env, cat /app/.env, or arbitrary network callbacks to internal services. Because the attack is delivered through the normal workflow API, no additional network exposure beyond the standard Coze Studio interface is required.

 # Default using local
 # - sandbox: execute python code in a sandboxed env with deno + pyodide
 # - local: using venv, no env isolation
-export CODE_RUNNER_TYPE="local"
+export CODE_RUNNER_TYPE="sandbox"
 # Sandbox sub configuration
 # Access restricted to specific environment variables, split with comma, e.g. "PATH,USERNAME"
 export CODE_RUNNER_ALLOW_ENV=""

Source: Coze Studio commit fcf40d1

Detection Methods for CVE-2026-77934

Indicators of Compromise

• Child python3 processes spawned by the Coze Studio service that in turn execute shell binaries such as sh, bash, curl, or wget.
• Workflow definitions or audit logs containing the string __import__( combined with subprocess, os, or pty.
• Outbound connections from the Coze Studio container to attacker-controlled hosts, or inbound connections to MySQL, MinIO, Redis, or etcd from the application process when such calls are not expected.
• Unexpected reads of .env, Kubernetes service account tokens, or cloud instance metadata endpoints by the application process.

Detection Strategies

• Hunt for process trees where the Coze Studio process is the parent of python3 and python3 is the parent of a shell or network utility.
• Parse workflow node content at ingestion for Python dunder-import patterns that evade the regex filter.
• Alert on reads of secret files or metadata URLs originating from the code runner process.

Monitoring Recommendations

• Enable verbose audit logging on the workflow API and ship logs to a centralized data lake for retrospective hunting.
• Monitor egress from Coze Studio hosts and baseline the expected destinations for model API calls, flagging deviations.
• Track configuration drift on CODE_RUNNER_TYPE and alert if it reverts to local after remediation.

How to Mitigate CVE-2026-77934

Immediate Actions Required

• Upgrade Coze Studio to version 0.5.0 or later, which sets CODE_RUNNER_TYPE="sandbox" by default.
• Set CODE_RUNNER_TYPE="sandbox" explicitly in every deployment .env file and restart the service.
• Rotate all secrets reachable from the Coze Studio host, including model API keys and credentials for MySQL, MinIO, Redis, and etcd.
• Audit existing workflows for Python nodes containing __import__, subprocess, os.system, or eval patterns.

Patch Information

The fix is delivered in commit fcf40d1, which changes the default CODE_RUNNER_TYPE to sandbox using the deno + pyodide runtime. Review the VulnCheck advisory and the Lasso Security entry for CVE-2026-77934 for additional vendor context. The default environment template is published at the Coze Studio .env.example reference.

Workarounds

• Restrict Coze Studio registration and workflow authoring permissions to trusted users only until the patch is applied.
• Run the Coze Studio container with a minimal set of mounted secrets and network egress rules that deny access to backend data stores from the application process.
• Use CODE_RUNNER_ALLOW_ENV to limit which environment variables the runner can read when sandbox mode is enabled.
• Place the service behind an authenticating reverse proxy and block unauthenticated access to the workflow API.

# Configuration example: enforce the sandboxed code runner
export CODE_RUNNER_TYPE="sandbox"
export CODE_RUNNER_ALLOW_ENV="PATH"