Flyto Core CVE-2026-67429

Exploitation requires a running flyto-core (< 2.26.6) workflow that invokes a file-writing module - image.download, document/excel_write, document/pdf_fill_form, or the browser/pagination checkpoint writer - with an output_dir/path that an attacker can influence, plus attacker control over the fetched response bytes (e.g., a caller-supplied download URL). The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates no authentication or user interaction, so where those parameters are exposed to untrusted input the write is unauthenticated and remote. Limiting factors: the attacker must be able to steer the output path and the source content, and writes are bounded by what the flyto-core process user can access on disk; deployments that hard-code output directories and URLs, or that already run with a tightly permissioned FLYTO_SANDBOX_DIR and least-privilege process account, substantially reduce realistic exposure.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H = 10.0) rates this maximally severe: network, low-complexity, unauthenticated, scope-changed integrity and availability impact via arbitrary write outside the sandbox. However, real-world risk hinges on a signal the raw vector obscures: the description says exploitation uses a 'caller-controlled output_dir' and 'attacker-controlled response bytes', so practical exploitation requires a deployed workflow that exposes the output path and/or fetched URL to untrusted input (e.g., an AI-agent step whose parameters are driven by external data). Where operators hard-code these values, exposure is materially lower than 10.0 suggests. No EPSS score, KEV listing, or POC was provided, so exploitation is currently no public exploit identified at time of analysis - not confirmed active. C:N is correct (write-only, no direct read), but arbitrary write commonly escalates to code execution or DoS, which is why I/A are High. Net: treat as high priority for anyone running flyto-core in a multi-tenant or untrusted-input configuration; lower urgency for fully operator-controlled deployments - but patch regardless given the trivial fix.

An attacker who can influence a flyto-core workflow's image.download step supplies a malicious source URL and an output_dir that traverses out of the sandbox (e.g., ../../etc or a startup/config directory). The engine fetches the attacker's response bytes and writes them verbatim to that path with the process's privileges, letting the attacker overwrite configuration, drop a script into an auto-executed location, or corrupt files for denial of service. No authentication or user interaction is required per the CVSS vector, and no public POC is currently identified.