Astron Agent local workflow executor ran unsandboxed code with cross-tenant database reach

The affected Astron Agent workflow code node claimed to provide restricted execution but passed Python the full builtins module. In the shipped local execution mode, a tenant-authorized workflow could start unrestricted code under the core-workflow container user, which had database access and privileged network reach. Researchers reproduced access to synthetic tenants through the shared MySQL and PostgreSQL services.

The vendor advisory and release identify 1.1.2 as the correction, with the old local executor rejected and isolated execution enabled by default. The advisory explicitly warns that updating only a checkout or a single image does not apply all changes: Docker Compose, service images, gateway and configuration must be migrated as a unit. The evidence is a reproduced architectural vulnerability in a controlled deployment, not proof of actual victim tenants.

There are two independent ways to reach the code sink in the advisory. A normal authenticated tenant can run a workflow code node under the default local executor; separately, an actor already on the application network or reaching its internal core-workflow endpoint can invoke that service without its own authentication. The local executor, service topology and shared database credentials explain why one tenant's workflow could act outside its own tenant database rows. Installing a corrected Python package without updating Compose and service images cannot establish that the running executor has changed.