CVE-2026-108263 in Astron Agent
Summary
by MITRE • 10/10/2026
Astron Agent is an agentic workflow platform for building and running AI agents. Prior to 1.1.2, the default workflow code-node path through /console-api/workflow/code/run and /workflow/v1/run selects LocalExecutor in core/workflow/engine/nodes/code/code_node.py when CODE_EXEC_TYPE is not explicitly changed. LocalExecutor supplies complete Python builtins to dynamic code execution without the documented sandbox restrictions. An authenticated low-privilege tenant can execute code as root in the core-workflow container and use shared service and database credentials to bypass application-level tenant checks, read or modify other tenants' data, and disrupt shared services. This issue is fixed in version 1.1.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified within Astron Agent prior to version 1.1.2 represents a critical failure in the isolation of multi-tenant AI agent workflows, specifically stemming from an insecure default configuration and inadequate sandboxing mechanisms for dynamic code execution. As an agentic workflow platform designed to build and run autonomous agents, Astron Agent relies on executing user-defined Python scripts within its core engine. The architecture utilizes specific API endpoints, namely /console-api/workflow/code/run and /workflow/v1/run, to trigger these executions. In versions preceding 1.1.2, the system defaults to using LocalExecutor when the environment variable CODE_EXEC_TYPE is not explicitly configured otherwise. This default behavior bypasses any intended security boundaries because LocalExecutor invokes Python with access to all built-in modules and functions without imposing the documented sandbox restrictions that are supposed to limit dangerous operations such as file system access or network connections.
From a technical perspective, this flaw constitutes an insecure default configuration combined with improper restriction of resource consumption and functionality, aligning closely with CWE-276: Incorrect Default Permissions and CWE-94: Improper Control of Generation of Code (Code Injection). The LocalExecutor implementation effectively grants the executing code full administrative privileges within the container environment. Because the execution occurs as the root user inside the core-workflow container, an attacker who gains access to any tenant account can leverage this privilege escalation to execute arbitrary system commands with root-level authority. This is not merely a sandbox escape in the traditional sense but rather a fundamental architectural flaw where the security boundary between tenants and the underlying infrastructure is non-existent by default. The lack of explicit configuration requirement for secure execution modes means that even users without advanced knowledge of the platform's security features are exposed to this risk upon initial deployment or standard usage.
The operational impact of this vulnerability is severe due to its multi-tenant nature. An authenticated low-privilege tenant can exploit this flaw to execute code as root, thereby gaining control over the container environment hosting the workflow engine. This level of access allows the attacker to read shared service credentials and database connection strings stored within the container's file system or environment variables. With these credentials in hand, the attacker can bypass application-level tenant isolation checks directly at the data layer. This enables unauthorized reading, modification, or deletion of other tenants' sensitive data, leading to significant confidentiality and integrity breaches. Furthermore, the ability to execute arbitrary commands allows for denial-of-service attacks against shared services, potentially disrupting operations for all users on the platform by consuming resources or terminating critical processes within the container.
This vulnerability maps directly to several techniques in the MITRE ATT&CK framework, particularly T1059: Command and Scripting Interpreter, as it involves executing arbitrary code via Python scripts. It also relates to T1534: Internal Spearphishing if used for lateral movement within a compromised environment, though more accurately it aligns with T1621: Credential Access through the extraction of database credentials from the container context. The ability to bypass tenant checks and access other tenants' data is indicative of a failure in logical access control, which can be categorized under CWE-862: Missing Authorization or CWE-925: Improper Mitigation for Exploitable Vulnerability when considering the broader security posture.
To mitigate this vulnerability, organizations must immediately upgrade to Astron Agent version 1.1.2 and later, where these default execution behaviors have been corrected. For environments that cannot update immediately due to compatibility constraints, it is imperative to explicitly set the CODE_EXEC_TYPE environment variable to a secure executor mode that enforces sandboxing restrictions before deploying or running any workflows. Additionally, administrators should audit container configurations to ensure that no sensitive credentials are stored in plaintext within the execution context and implement network policies to restrict outbound connections from the workflow containers unless strictly necessary for legitimate agent operations. Regular security assessments focusing on multi-tenant isolation and dynamic code execution safety are recommended to prevent similar architectural flaws in future deployments or custom integrations.