Flyto Core EUVD-2026-50471

Exploitation requires two things: (1) the operator relies on the capability policy denylist for env.get / env.load_dotenv to protect host secrets (the default posture the advisory describes), and (2) the attacker can place a ${env.VAR} token into a workflow step parameter that passes through the engine's variable resolver. Because interpolation happens in the engine before the module chokepoint, the denylist provides no protection - that pre-chokepoint expansion IS the enabling condition. What limits exploitation: the attacker must be able to control or inject a workflow parameter, so exposure is highest in deployments where untrusted data (agent inputs, tenant-submitted workflows) reaches parameters, and lower where only trusted operators author workflows; there is also no impact if the host environment holds no secrets. Authentication level for parameter submission is not confirmed from the provided data. After the 2.26.6 fix, exploitation additionally requires that the target name be present in FLYTO_ENV_VAR_ALLOWLIST or that env.get be explicitly allowed.

The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, 8.6) portrays a high-severity, unauthenticated, low-complexity, confidentiality-only issue with scope change - consistent with a sandbox-escape that reaches host secrets. The real determinant of exploitability is who controls a workflow parameter: in agentic deployments untrusted external data commonly flows into workflow parameters (supporting PR:N), but in operator-authored-only deployments the practical attacker must already be able to submit or influence workflow content, which raises the bar. No EPSS score, KEV entry, SSVC decision, or public POC was provided, so exploitation-in-the-wild cannot be asserted; this is currently a high-CVSS finding whose weaponization is unproven. The scope change and C:H are well justified because secrets belong to a different trust boundary (the host env) than the workflow sandbox the policy governs. Key uncertainty to verify with the vendor: whether workflow parameters are reachable by unauthenticated/untrusted sources in the target deployment - this determines whether PR:N is realistic or overstated.

An attacker who can influence a workflow parameter (for example, untrusted content processed by an AI-agent workflow, or a submitted job in a multi-tenant automation setup) inserts ${env.AWS_SECRET_ACCESS_KEY} or ${env.OPENAI_API_KEY} into a field. The engine's variable resolver expands it against the host environment before the module policy runs, so even though env.get is denylisted the secret is inlined and then carried out through an allowed module (e.g. an HTTP or model call). No public exploit code was provided, but the attack is low-complexity once parameter influence exists.