Astron Agent's Default Code Executor Ran Tenant Python as Root; Version 1.1.2 Closes It

A critical flaw in Astron Agent, iFlytek’s open-source platform for building and running AI agent workflows, let any authenticated user who could build a workflow run arbitrary Python as root inside the platform’s workflow container. Tracked as CVE-2026-108263 with a CVSS 3.1 score of 9.9, the issue affects all releases through v1.1.1 and is fixed in v1.1.2. The CVE record was published on October 9, 2026, at 21:17 UTC (October 10, 02:47 IST). The fix itself is not new: the project’s GitHub security advisory, GHSA-mh3w-4q3f-2fg5, is dated September 7, 2026, and the v1.1.2 security release was published on GitHub the same day.

Astron Agent lets teams wire models, tools and custom logic into visual workflows. One building block is a code node, where a user supplies Python to transform data between steps. In multi-tenant deployments, many organizations share the same backend, so the code node is exactly the kind of feature that needs strong isolation.

A sandbox that existed only in a docstring

The project’s advisory says the default executor for code nodes, selected whenever operators left the executor setting unchanged, was described in its own source as using RestrictedPython for secure execution. RestrictedPython was not a project dependency, and no restriction was implemented. Submitted code received the complete set of Python built-ins and ran in a child process in the same container, as the same root user, on the same network and filesystem.

The shipped Docker Compose configuration set that unsandboxed executor as the default, so an operator following the standard deployment instructions received it without opting in. The advisory also notes that all services shared a single bridge network and that the compose files shipped well-known default passwords for the bundled databases and object storage, along with sample tenant secrets in the example environment file.

How one tenant could reach another tenant’s data

The console’s own space and tenant authorization logic worked correctly, according to the researchers. The problem was that code running in the executor never passed through it. With root inside the container and reachable databases using default credentials, code could connect to shared stores directly, where application-level tenant checks did not apply. The advisory lists cross-tenant reads, modification or deletion of other tenants’ data, theft of shipped secrets and disruption of the whole platform as possible outcomes. An internal execution route also lacked authentication; the default reverse-proxy configuration blocked it from the outside, but it remained reachable from inside the service network.

Single-tenant installations are not cross-tenant exposed but still face the code-execution and credential risk. The weakness classes cited include eval injection (CWE-95), improper compartmentalization (CWE-653), missing authentication (CWE-306), incorrect authorization (CWE-863) and use of default credentials (CWE-1392). Noy Pearl and the Lasso Security team are credited with responsible disclosure and with verifying the fix.

What v1.1.2 changes

The patched release rejects unsafe local code execution and turns on the built-in isolated LangChain/Pyodide executor by default, with E2B remaining an optional backend. The legacy local executor setting is no longer supported. iFlytek says the release also strengthens authentication on internal workflow and tenant APIs, tightens tenant checks and credential handling, improves deployment isolation and adds outbound SSRF protection for plugins.

Upgrade checklist for operators

The project stresses that updating a source checkout or a single service image does not apply the complete fix. Its guidance, summarized:

• Back up databases, persistent data and configuration before upgrading.
• Update the Compose deployment files, service configuration, gateway configuration and every service image together, keeping site-specific settings. For Docker Compose, pin the release version to v1.1.2 and recreate the stack from the published images.
• Verify service health and confirm workflow code nodes execute in the isolated runtime after the upgrade.
• Review custom executor settings and adapt any workflow code that depended on host filesystem, environment variables, subprocesses or network access.

Beyond the vendor’s steps, the advisory’s findings point to standard hardening. Replace every default database, cache and storage password and any sample tenant secret that came from the example files, and treat those values as compromised on any instance that ran an affected version with untrusted users. Restrict who can create or edit workflows until the upgrade lands, keep internal service ports off public networks, and review database audit logs for unexpected direct connections from the workflow container.

The case fits a growing pattern in agent tooling: platforms that let users or models run code are only as safe as the execution layer underneath, and a security property promised in documentation needs to be checked against what the code actually does.