CVE-2026-108263: Astron Agent Unsandboxed Workflow Code Execution

Overview

Astron Agent is iFLYTEK's open-source, enterprise-grade agentic workflow platform for building and running AI agents — it combines workflow orchestration, model management, tool/MCP integration, and RPA automation. CVE-2026-108263 (CVSS 9.9, Critical) is an insecure-default vulnerability in the platform's "code node" feature: the workflow code-execution path reachable via /console-api/workflow/code/run and /workflow/v1/run falls back to an unsandboxed LocalExecutor whenever the CODE_EXEC_TYPE setting is left at its default. Any authenticated, low-privilege tenant able to submit a workflow can use this to run arbitrary Python as root inside the core-workflow container. The issue was published 2026-10-09 and is fixed in version 1.1.2.

Technical Details

How It Works

Astron Agent's "code node" lets workflow authors embed custom Python that runs as part of the agent pipeline — a deliberate feature for extending agent logic. To make that safe, the platform documents a sandboxed execution mode. The bug is that the executor selection is controlled by the CODE_EXEC_TYPE configuration value, and when an operator never explicitly sets it, the code path silently falls back to LocalExecutor. That executor hands the submitted code the complete Python builtins module with no allow-list — none of the documented sandbox restrictions on filesystem access, process spawning, or network calls are actually enforced. Because the two run endpoints accept and execute workflow code directly, any authenticated low-privilege tenant who can submit or run a workflow gets the equivalent of a raw Python shell inside the core-workflow container, running with root privileges. From there, shared service and database credentials baked into the container let the attacker step around application-level tenant checks entirely, reaching other tenants' data and shared infrastructure.

Impact Assessment

Who Is At Risk

• Any organization running a self-hosted Astron Agent instance ≤ 1.1.1 that has not explicitly overridden CODE_EXEC_TYPE to a sandboxed executor
• Multi-tenant deployments are especially exposed — the privilege bar to exploit is only a low-privilege, authenticated tenant account, not an admin
• Deployments reachable from an internal network, or exposed indirectly through an SSRF vulnerability elsewhere in the stack, may not even need valid tenant credentials to reach the vulnerable endpoints

Attack Chain

1. Attacker obtains or already holds a low-privilege, authenticated tenant account on a vulnerable Astron Agent instance (≤ 1.1.1, CODE_EXEC_TYPE unset)
2. Attacker creates or edits a workflow containing a code node with a malicious Python payload
3. Attacker triggers execution via /console-api/workflow/code/run or /workflow/v1/run
4. The platform selects LocalExecutor by default, running the payload with full interpreter access and root privileges inside the core-workflow container
5. Attacker uses the shared database/service credentials present in the container to bypass application-level tenant isolation
6. Attacker reads, modifies, or deletes other tenants' data, and/or disrupts shared services to cause a platform-wide outage

Mitigation

Immediate Actions

• Upgrade to Astron Agent 1.1.2 or later, which rejects unsafe local execution and defaults to an isolated, sandboxed executor
• If upgrading isn't immediately possible, explicitly set CODE_EXEC_TYPE to the sandboxed executor mode documented by the project — do not rely on the default
• Rotate any shared service/database credentials baked into the core-workflow container image or environment, since they should be treated as exposed in any instance that was ever vulnerable
• Audit recent workflow code-node submissions and executions for anomalous behavior

Detection Opportunities

• Unexpected child processes spawned by the core-workflow container, especially shells, package managers, or network utilities
• Outbound network connections originating from workflow code execution that don't match expected integration targets
• Filesystem access from the workflow engine outside its normal working directories
• Authentication or database access events on shared credentials from the core-workflow service account that don't correlate with legitimate service activity

Defence-in-Depth

• Network-isolate the Astron Agent platform; don't expose /console-api/workflow/code/run or /workflow/v1/run beyond what's strictly necessary
• Run the core-workflow container with a least-privilege, non-root host user and strict container isolation regardless of the application-level executor setting
• Monitor and rate-limit workflow submission endpoints, and alert on code nodes containing unusual imports or system-level calls
• Treat multi-tenant credential and secret storage as a hard isolation boundary — don't rely solely on application-layer tenant checks

Background

AI agentic-workflow platforms increasingly expose a "run arbitrary code" primitive as a first-class feature — code nodes, tool plugins, and script steps are what make agents useful for real automation. That same primitive is exactly what a sandbox is supposed to contain, which makes insecure-by-default sandboxing in this category unusually dangerous: a configuration variable nobody thought to set turns an intended extensibility feature into unrestricted host access, often for every tenant on a shared deployment at once. As more organizations adopt self-hosted agent platforms like Astron Agent, verifying that sandboxing is actually enforced — not just documented — deserves the same scrutiny as authentication and authorization controls.

References

• NVD — CVE-2026-108263
• GitHub Security Advisory GHSA-mh3w-4q3f-2fg5 — iflytek/astron-agent
• iflytek/astron-agent — GitHub repository
• iflytek/astron-agent v1.1.2 release