Summary
Astron Agent contains an unsafe dynamic code-execution path in its default workflow code-node configuration. An authenticated low-privilege tenant may execute arbitrary Python code as root in the core-workflow container when the default executor is used, potentially exposing shared credentials and other tenants' data.
Astron Agent contains an unsafe dynamic code-execution path in its default workflow code-node configuration. An authenticated low-privilege tenant may execute arbitrary Python code as root in the core-workflow container when the default executor is used, potentially exposing shared credentials and other tenants' data.
Affected context
The vulnerability occurs in Astron Agent deployments that use the default workflow code-node execution path through the workflow run APIs. It is relevant when CODE_EXEC_TYPE remains configured to select LocalExecutor, which provides unrestricted Python builtins instead of the documented sandbox restrictions. Exploitation also depends on an authenticated tenant being able to submit or invoke workflows containing code-node execution.
The vulnerability occurs in Astron Agent deployments that use the default workflow code-node execution path through the workflow run APIs. It is relevant when CODE_EXEC_TYPE remains configured to select LocalExecutor, which provides unrestricted Python builtins instead of the documented sandbox restrictions. Exploitation also depends on an authenticated tenant being able to submit or invoke workflows containing code-node execution.
Exploit preconditions
- Attack surface: Workflow execution APIs, including the console and workflow run endpoints
- Required access: Authenticated access available to a low-privilege tenant
- Trigger point: Execution of a workflow code node through the default
LocalExecutorpath - Why exploitation is possible: Dynamic code executes with complete Python builtins and elevated container privileges rather than within an effective sandbox
- Additional risk factor: Shared service or database credentials available to the workflow container may enable access beyond the attacker's tenant
- Attack surface: Workflow execution APIs, including the console and workflow run endpoints
- Required access: Authenticated access available to a low-privilege tenant
- Trigger point: Execution of a workflow code node through the default
LocalExecutorpath - Why exploitation is possible: Dynamic code executes with complete Python builtins and elevated container privileges rather than within an effective sandbox
- Additional risk factor: Shared service or database credentials available to the workflow container may enable access beyond the attacker's tenant
Why this happens
The underlying flaw is unrestricted execution of tenant-influenced workflow code in a privileged application process. Selecting LocalExecutor by default exposes complete Python builtins and fails to enforce the intended isolation boundary, allowing dynamic code to access operating-system functionality and process resources. This maps primarily to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code, with related concerns involving missing authorization, broken tenant isolation, and insufficient sandboxing.
The underlying flaw is unrestricted execution of tenant-influenced workflow code in a privileged application process. Selecting LocalExecutor by default exposes complete Python builtins and fails to enforce the intended isolation boundary, allowing dynamic code to access operating-system functionality and process resources. This maps primarily to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code, with related concerns involving missing authorization, broken tenant isolation, and insufficient sandboxing.
Potential impact
- An attacker may execute arbitrary Python or operating-system actions in the core-workflow container.
- The attacker could obtain or misuse shared service and database credentials.
- Other tenants' data may be read, altered, or deleted.
- Application-level tenant authorization checks could be bypassed.
- Shared services may be disrupted or misused.
- A compromised container could provide a foothold for further internal access, depending on deployment permissions.
- An attacker may execute arbitrary Python or operating-system actions in the core-workflow container.
- The attacker could obtain or misuse shared service and database credentials.
- Other tenants' data may be read, altered, or deleted.
- Application-level tenant authorization checks could be bypassed.
- Shared services may be disrupted or misused.
- A compromised container could provide a foothold for further internal access, depending on deployment permissions.
General mitigation guidance
Mitigation generally focuses on removing unrestricted dynamic execution from tenant-controlled workflows and enforcing a genuine isolation boundary.
Common defensive patterns include:
- Use a deny-by-default, capability-limited execution model rather than a local process with complete Python builtins.
- Run workflow code in strongly isolated, short-lived sandboxes with minimal filesystem, network, credential, and operating-system access.
- Keep code execution disabled unless explicitly required and securely configured.
- Do not expose shared service credentials to workflow execution environments; use narrowly scoped, short-lived identities where access is necessary.
- Enforce tenant authorization independently at every data and service boundary, rather than relying on workflow-level checks.
- Run workflow workers as non-root identities with least-privilege container and platform permissions.
- Apply resource, timeout, network-egress, and concurrency limits to reduce abuse and service disruption.
Mitigation generally focuses on removing unrestricted dynamic execution from tenant-controlled workflows and enforcing a genuine isolation boundary.
Common defensive patterns include:
- Use a deny-by-default, capability-limited execution model rather than a local process with complete Python builtins.
- Run workflow code in strongly isolated, short-lived sandboxes with minimal filesystem, network, credential, and operating-system access.
- Keep code execution disabled unless explicitly required and securely configured.
- Do not expose shared service credentials to workflow execution environments; use narrowly scoped, short-lived identities where access is necessary.
- Enforce tenant authorization independently at every data and service boundary, rather than relying on workflow-level checks.
- Run workflow workers as non-root identities with least-privilege container and platform permissions.
- Apply resource, timeout, network-egress, and concurrency limits to reduce abuse and service disruption.
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving dynamic evaluation, unrestricted Python builtins, local code executors, or subprocess and operating-system access in workflow components.
- Code-review signals showing tenant-controlled code executing in the API or worker process, especially when sandbox selection is controlled by a default or weakly protected setting.
- Runtime telemetry for unexpected child processes, filesystem access, network connections, credential reads, or privileged actions from workflow workers.
- Authorization tests that attempt cross-tenant reads and writes through workflow execution paths.
- Policy enforcement requiring non-root workers, restricted network egress, secret minimization, and isolated execution for untrusted code.
- Automated security review tools that flag dangerous dynamic execution and missing authorization checks.
Organizations can look for:
- Static-analysis findings involving dynamic evaluation, unrestricted Python builtins, local code executors, or subprocess and operating-system access in workflow components.
- Code-review signals showing tenant-controlled code executing in the API or worker process, especially when sandbox selection is controlled by a default or weakly protected setting.
- Runtime telemetry for unexpected child processes, filesystem access, network connections, credential reads, or privileged actions from workflow workers.
- Authorization tests that attempt cross-tenant reads and writes through workflow execution paths.
- Policy enforcement requiring non-root workers, restricted network egress, secret minimization, and isolated execution for untrusted code.
- Automated security review tools that flag dangerous dynamic execution and missing authorization checks.
