RestrictedPython was never a dependency

Astron Agent is iFlytek’s open-source agent platform, self-hosted through a Docker Compose stack the project publishes as docker/astronAgent. Workflows built in it can contain a code node, a block where a user writes Python that the platform executes as part of the agent’s run. CVE-2026-108263, published on 9 October 2026 through GitHub’s CNA and scored 9.9, concerns what was executing that Python.

The executor’s own documentation strings describe a sandbox. One, quoted in the advisory, reads “Local code executor using RestrictedPython for secure execution.” The report, by Noy Pearl, Michael Asso, and Ophir Dror of Lasso Security, states that RestrictedPython does not appear in the project’s dependencies and that no such restriction was implemented. What the local executor actually did was start a multiprocessing.Process with a timeout. The child ran as root, in the same container, on the same filesystem and the same network as the service, with import parsing that enforced no allow-list and __builtins__ set to the complete builtins module.

That executor was the shipped default. The backend falls back to CODE_EXEC_TYPE, which defaults to “local” unless a sandbox configuration is present, and both the shipped config.env and app_config.py default to local. An operator who deployed the published Compose stack and changed nothing got the unsandboxed path, reachable by any authenticated low-privilege tenant through /console-api/workflow/code/run or /workflow/v1/run.

The stack puts every service on one Docker bridge network, with credentials shipped in the defaults: PostgreSQL spark/spark123 as a superuser, MySQL root/root123, MinIO minioadmin/minioadmin123, and an unauthenticated Redis. The .env.example file also carries hardcoded tenant secrets. The advisory is explicit that the console’s own authorization logic is sound. The problem is that code running in a node connects straight to those databases with those credentials, so the tenant and space checks the console enforces are never in the path at all.

The report adds a fourth element. The internal routes POST /run and /code/run, under /workflow/v1 and /sparkflow/v1, require no authentication, because the middleware in front of them trusts a client-supplied x-consumer-username header. Nginx returns 404 for those paths from outside, so reaching them depends on internal network access or a server-side request forgery pointing at core-workflow:7880, and v1.1.2 also fixes an SSRF in outbound plugin requests. Lasso ran two tests on its own deployments using benign canary values, first against the full stack with default settings and an authenticated tenant token, then against a minimal harness around the v1.1.1 executor; the first confirmed root execution and cross-tenant read and write, and the second confirmed root execution, database superuser access, and cross-tenant read and write.

The privilege line in the vector is the part worth sitting with. PR:L means an attacker needs an account, but on a multi-tenant agent platform an account is the product, so every customer who can build a workflow holds the privilege the flaw requires. The scope change to S:C follows: what is compromised is not the tenant’s own workspace but the shared databases underneath every tenant’s workspace. What distinguishes this from an ordinary missing-sandbox finding, as the analysis puts it, is that the sandbox was documented. A docstring saying “using RestrictedPython for secure execution” is the artifact a reviewer reads, and the dependency list that would have contradicted it in one grep is not where anyone looks after reading a direct statement in the code.

The fix is version 1.1.2, release commit 189600d, which makes the isolated LangChain/Pyodide executor the default and rejects the unsafe local path; CODE_EXEC_TYPE=local is no longer supported. The project is specific that a partial upgrade does not apply the fix: updating only the source checkout, or only the workflow service image, leaves the exposure in place, so the Compose files, configuration, gateway, and all service images must move together. The release note also warns that “Automated vulnerability scanners may not flag this application-level issue” and to verify the deployed image versions explicitly; Severity Daily adds that the vulnerable configuration is a default in a Compose file rather than a package version, so an organization that relies on image scanning to tell it whether it is exposed will be told it is fine.

The underlying advisory and the v1.1.2 release both landed on 7 September 2026, and the CVE record was published on 9 October, so the record caught up with the fix 32 days later. No exploitation has been reported by the project, by Lasso Security, or by any source checked, and the finding is single-sourced to Lasso’s report and the project’s confirmation of it. It belongs to the same family as the other documented-control findings: the safety mechanism existed as a description and a configuration surface, and the dangerous operation stayed reachable through the default path.