Flyto2 Core: Arbitrary File Write in image.download Bypasses Sandbox Confinement (CVE-2026-67429)

What happened

A newly published GitHub Security Advisory (GHSA-2956-977x-2w3r) reports a critical vulnerability in flyto-core, the pip package underlying Flyto2's module system. According to the advisory, the image.download module fetches attacker-influenced URLs and writes the response body to disk, but instead of using the platform's central path guard (validate_path_with_env_config, which confines writes to FLYTO_SANDBOX_DIR), it validates the output path against a caller-supplied output_dir parameter. Because the attacker controls both the target path and the base directory it's checked against, the confinement check is reported to be trivially bypassable, allowing arbitrary content to be written to any path the process can access. The advisory notes the same missing-guard pattern affects a list of other file-writing modules (including image.convert, document.excel_write, document.pdf_fill_form, and several others), though those are described as format-constrained rather than accepting fully arbitrary bytes. The advisory assigns CVE-2026-67429 with a CVSS of 10.0 and includes a public proof-of-concept.

Why it matters

Per the advisory, these module parameters (output_dir, output_path, url) are not restricted to trusted operators — they are exposed through a generic execute_module MCP tool callable by an AI agent processing untrusted content, or by remote/hosted-API clients. That reachability path is what elevates this from a configuration issue to a serious vulnerability: an attacker who can influence the parameters an LLM passes to this module (e.g., via prompt injection or a malicious hosted request) could write attacker-controlled bytes to an arbitrary filesystem location. The advisory describes potential outcomes such as overwriting configuration, planting a shell profile or cron job, tampering with authorized_keys, or replacing a Python module — any of which could lead to code execution in typical deployments.

What defenders should watch for now

• If you deploy Flyto2 / flyto-core, especially with MCP-exposed module execution or hosted-API access, review whether affected modules (image.download and the other listed file-writing modules) are reachable by agent or remote-controlled parameters in your environment.
• Watch for unexpected file writes outside expected sandbox/output directories, particularly to sensitive paths such as SSH authorized_keys, cron directories, shell profile files, or application config/module paths.
• Review logs for outbound HTTP requests to unfamiliar external hosts initiated by image/document-processing modules, since the reported exploitation path relies on the module fetching attacker-hosted content.
• Until a patched release is confirmed, consider restricting or disabling exposure of these modules to untrusted or LLM-driven callers, and enforce filesystem-level controls (e.g., running the process with least-privilege write access) as compensating controls.

This is a same-day, developing item based on a newly published advisory with a public proof-of-concept; details around vendor patch status and broader exploitation may evolve. For the full technical write-up, affected module list, and PoC, see the original advisory: GHSA-2956-977x-2w3r.