Astron Agent CVE-2026-108263

Exploitation requires that CODE_EXEC_TYPE is left at its pre-1.1.2 default (not explicitly set), which causes code_node.py to select LocalExecutor - the vulnerable, sandbox-free path; this is the shipped default so most unmodified deployments qualify. The attacker must hold a valid low-privilege tenant account (PR:L) and be able to create/run a workflow containing a Code node, reachable via /console-api/workflow/code/run or /workflow/v1/run. Limiting factors: authentication to a tenant is mandatory (not anonymous), and deployments that explicitly set CODE_EXEC_TYPE to 'disabled' or the isolated LangChain/Pyodide sandbox, or that have upgraded to 1.1.2, are not exposed.

This is a genuine high-priority issue, not a CVSS-inflation artifact. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) is internally consistent with the description: a network-reachable workflow endpoint (/console-api/workflow/code/run and /workflow/v1/run), low attack complexity, only low-privilege tenant authentication required (PR:L), no user interaction, and a scope change (S:C) because code runs as root inside the shared core-workflow container and reaches other tenants' data and shared services via shared DB/service credentials. The scope change plus full CIA 'High' impact is well-justified by the described tenant-isolation break. EPSS score was NOT provided, so exploitation probability cannot be quantified. KEV status is not listed (treat as not in KEV). No public exploit code is referenced - the GitHub artifacts are the fix (PRs #1650/#1651, two commits, release v1.1.2 and the GHSA advisory), NOT a POC. The key risk amplifier is that the vulnerable LocalExecutor is the DEFAULT path when CODE_EXEC_TYPE is unchanged, so typical deployments are exposed out of the box; the only mitigating signal is that authentication (a tenant account) is required, making this authenticated rather than fully anonymous RCE.

An attacker who holds any low-privilege tenant account on an Astron Agent instance (prior to 1.1.2, default config) builds a workflow containing a Code node and submits malicious Python via /console-api/workflow/code/run or /workflow/v1/run. Because LocalExecutor exposes full Python builtins with no sandbox, the code runs as root in the core-workflow container, from which the attacker uses shared service/database credentials to bypass tenant checks and read or alter other tenants' data. No public POC is referenced, but the attack requires no special exploitation skill given low attack complexity.