CVE-2026-82278: BISHENG Workflow RCE Vulnerability

CVE-2026-82278 Overview

CVE-2026-82278 is an authenticated remote code execution vulnerability in BISHENG versions before 2.6.0. The flaw resides in the workflow run_once endpoint, which processes user-submitted Code node definitions without sandboxing. Authenticated attackers can submit crafted Python payloads to the POST /api/v1/workflow/run_once endpoint, which passes them directly to Python's exec() function. Successful exploitation grants attackers arbitrary code execution on the BISHENG backend server, exposing the filesystem, stored credentials, and internal network resources reachable from the host. The vulnerability is classified as Improper Control of Generation of Code [CWE-94].

Critical Impact
Any authenticated user can execute arbitrary Python code on the BISHENG server, leading to full backend compromise, credential theft, and pivoting into internal networks.

Affected Products

BISHENG (dataelement/bisheng) versions before 2.6.0
BISHENG v2.4.0 workflow service (confirmed vulnerable in src/backend/bisheng/api/services/workflow.py)
All deployments exposing the /api/v1/workflow/run_once endpoint to authenticated users

Discovery Timeline

2026-08-28 - CVE-2026-82278 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-82278

Vulnerability Analysis

BISHENG is an open-source large language model application development platform that supports workflow orchestration through composable node types. One node type, the Code node, allows workflow authors to embed Python logic that runs as part of a workflow execution. The run_once endpoint exists to let users test a workflow definition before saving it.

When a client posts a workflow definition to POST /api/v1/workflow/run_once, the backend parses the JSON payload and executes each Code node's Python source using the built-in exec() function. No sandbox, restricted namespace, syscall filter, or container boundary isolates the executed code from the host process. Any authenticated user with permission to reach the endpoint gains code execution with the privileges of the BISHENG backend process.

Because the backend typically holds API keys for LLM providers, database credentials, and network access to internal services, the impact extends well beyond the application itself. Attackers can read /etc/passwd, extract environment variables containing secrets, and initiate outbound connections to reach internal APIs.

Root Cause

The root cause is unsafe evaluation of untrusted input. The workflow service treats Code node contents as trusted developer logic when in fact the endpoint accepts arbitrary attacker-controlled Python source. Passing user input to exec() without an allowlist of permitted operations or an isolation boundary is the canonical [CWE-94] pattern.

Attack Vector

Exploitation requires network access to the BISHENG API and valid authentication credentials. The attacker constructs a workflow JSON payload containing a Code node whose Python source performs the desired action, such as calling os.system, importing subprocess, or reading files. Submitting the payload to POST /api/v1/workflow/run_once triggers execution immediately, without saving the workflow or requiring administrative approval.

The vulnerability manifests in the workflow execution path in src/backend/bisheng/api/services/workflow.py. See the VulnCheck Security Advisory and the GitHub Issue Tracker #2189 for technical details.

Detection Methods for CVE-2026-82278

Indicators of Compromise

HTTP requests to POST /api/v1/workflow/run_once containing Code node definitions with imports of os, subprocess, socket, ctypes, or pty.
Unexpected child processes spawned by the BISHENG backend process, such as sh, bash, python -c, or curl originating from the application user.
Outbound network connections from the BISHENG host to unfamiliar external IPs shortly after workflow API activity.
Filesystem reads of sensitive paths such as /etc/shadow, ~/.aws/credentials, or .env files by the BISHENG process.

Detection Strategies

Enable verbose access logging on the BISHENG API and alert on any authenticated call to /api/v1/workflow/run_once that includes a type: code node.
Deploy endpoint detection on the host running BISHENG to identify anomalous process ancestry originating from the Python interpreter.
Instrument the application to log the full contents of Code node payloads submitted via run_once for retrospective review.

Monitoring Recommendations

Baseline the normal workflow execution pattern and alert on volume spikes or off-hours activity against run_once.
Monitor for BISHENG service accounts authenticating from new source IPs or user agents.
Correlate workflow API activity with outbound egress traffic to detect data exfiltration attempts.

How to Mitigate CVE-2026-82278

Immediate Actions Required

Upgrade BISHENG to version 2.6.0 or later, which contains the vendor fix for this vulnerability.
Restrict network access to the BISHENG API using firewall or reverse-proxy allowlists until patching is complete.
Rotate all secrets, API keys, and database credentials accessible to the BISHENG backend process, since authenticated users on unpatched versions may have already exfiltrated them.
Audit BISHENG user accounts, disable unused accounts, and enforce strong password and MFA policies for accounts that can reach workflow endpoints.

Patch Information

Upgrade to BISHENG 2.6.0 or later from the GitHub Project Repository. Review the VulnCheck Security Advisory for release-specific guidance and confirm the fixed version before deploying to production.

Workarounds

Block or reverse-proxy-deny the /api/v1/workflow/run_once route until the upgrade is complete.
Run the BISHENG backend inside a restricted container with a read-only root filesystem, dropped Linux capabilities, and a seccomp profile that blocks execve of unexpected binaries.
Place the BISHENG deployment on an isolated network segment with strict egress filtering to limit lateral movement in the event of exploitation.

bash

# Example reverse-proxy block for the vulnerable route (nginx)
location = /api/v1/workflow/run_once {
    return 403;
}