CVE-2026-82278 in Bisheng
Summary
by MITRE • 08/28/2026
BISHENG before 2.6.0 contains a remote code execution vulnerability in the workflow run_once endpoint that allows authenticated users to execute arbitrary Python code. Attackers can submit crafted Code node definitions to the POST /api/v1/workflow/run_once endpoint, which executes them with exec() without sandboxing, gaining access to filesystem, credentials, and internal network resources.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in BISHENG versions prior to 2.6.0 represents a critical remote code execution flaw located within the workflow management subsystem. Specifically, this security issue resides in the run_once endpoint of the application's API interface. The core technical deficiency is the lack of proper input validation and sandboxing mechanisms when processing user-supplied data for Code nodes within workflows. When an authenticated user submits a request to the POST /api/v1/workflow/run_once endpoint containing a crafted Code node definition, the backend system directly passes this code into Python's exec() function without any protective isolation layers. This architectural oversight allows arbitrary Python code to be executed with the same privileges as the application process itself, effectively bypassing standard security controls that should restrict such operations in a multi-tenant or workflow-based environment.
From an operational perspective, the impact of this vulnerability is severe due to the unrestricted nature of the execution context. Because the exec() function runs without sandboxing, attackers who successfully exploit this flaw gain full control over the underlying operating system processes running BISHENG. This includes direct access to the local filesystem, enabling the reading or modification of sensitive configuration files, logs, and stored data. Furthermore, since many workflow applications handle credentials for external services or databases within their execution environment, an attacker can extract these secrets from memory or disk. The compromise extends beyond the immediate host, as the compromised process may have network access to internal resources, allowing lateral movement within the organization's infrastructure. This transforms a simple authentication bypass into a complete system takeover scenario.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), specifically where user input is directly executed without sanitization or sandboxing. It also maps closely to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, particularly the Python subcategory, as well as T1203 Executable File Execution if the attacker leverages the code execution to deploy additional payloads. The lack of isolation is a common pitfall in workflow orchestration tools that prioritize developer flexibility over security boundaries, but it remains a high-risk configuration error according to industry best practices for secure software development.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. The primary and most effective solution is to upgrade BISHENG to version 2.6.0 or later, where the vendor has addressed this specific flaw by implementing proper sandboxing or restricting code execution capabilities. For environments that cannot immediately patch due to compatibility constraints, network-level controls should be enforced to restrict access to the /api/v1/workflow/run_once endpoint exclusively to trusted IP ranges and enforce strict authentication policies with multi-factor authentication to reduce the attack surface. Additionally, running the application in a containerized environment with restricted capabilities can limit the blast radius of any successful exploitation by preventing access to sensitive host resources like filesystems and network interfaces outside the designated scope.