CVE-2026-67429: Arbitrary File Write and Path Traversal in Flyto2 Core Modules

Flyto2 Core functions as an execution kernel designed to orchestrate automation and AI-agent workflows. Within this environment, workflow tasks frequently require file operations, including downloading resources, converting documents, and processing images. To expose these capabilities safely, the application implements distinct modules that handle write operations to the local filesystem.\n\nSecurity bounds must restrict these modules from accessing critical system files. However, CVE-2026-67429 introduces a validation flaw within multiple file-writing routines, most prominently the image.download module. This weakness permits unauthenticated remote callers to bypass directory confinement controls entirely.\n\nAn unauthenticated remote attacker can exploit this weakness by submitting malicious payloads through exposed execution interfaces. By manipulating parameters, the caller can execute arbitrary file writes outside the intended confinement directory. The security consequence is complete system integrity compromise, which serves as a baseline for achieving remote code execution.

The root cause of CVE-2026-67429 resides in an insecure path validation scheme within src/core/modules/atomic/image/download.py. The validation routine attempts to verify that the destination file path stays within the boundaries of a target directory. However, the system relies on user-supplied input values to define both the validation base and the final file output path.\n\nTo evaluate directory containment, the codebase uses the Python standard library function os.path.commonpath. This function identifies the longest common sub-path among a list of provided directories. The validation logic checks if the common path matches the designated base path, throwing an error if there is a mismatch. Because both paths originate from the attacker-controlled parameter payload, the attacker can manipulate the base directory coordinate to match any targeted output path.\n\nFor example, setting the base directory to root / and the destination file path to /etc/cron.d/pwn_cron causes the validation mechanism to check the common path between / and /etc/cron.d/pwn_cron. This calculation returns / as the common ancestor. Since the resolved common path matches the attacker-supplied base directory /, the verification succeeds without triggering an exception. This structural flaw effectively transforms the validation step into a no-op whenever overlapping values are supplied.\n\nFurthermore, the validation routine was entirely absent in twelve other file-manipulation modules. Modules performing operations such as image formatting, scaling, QR code generation, and Excel compilation wrote files directly to user-defined paths. The combination of an insecure validation check in the download module and a total lack of validation in sister modules created a broad attack surface across the framework.

To visualize the vulnerability mechanics, examine the vulnerable source code compared to the remediated implementation. The original code in image/download.py extracted the base and target parameters directly from the user's action configuration payload.\n\npython\n# PRE-FIX INSECURE PATH VALIDATION\n# Both variables are derived from user-controlled parameters\nbase_real = os.path.realpath(output_dir)\ntarget_real = os.path.realpath(output_path)\n\n# The check fails to use a static, trusted server-side constant\nif os.path.commonpath([base_real, target_real]) != base_real:\n raise Exception(\'Invalid file path\')\n\n\nThe patched code introduces a centralized validation routine named validate_path_with_env_config. This function retrieves the base directory from the static environment variable FLYTO_SANDBOX_DIR instead of trusting user input parameters.\n\npython\n# POST-FIX SECURE SANITIZATION\ntry:\n # The validation function enforces confinement to FLYTO_SANDBOX_DIR\n target_real = validate_path_with_env_config(output_path)\nexcept PathTraversalError as e:\n raise ModuleError(str(e), code=\"PATH_TRAVERSAL\")\n\n\nIn document modules like excel_write.py, the remediation follows a similar pattern. The system intercepts the write path and enforces the sandbox check before executing directory creation or writing workbook bytes to the disk, mitigating the traversal vector systematically across all filesystems sinks.

The exploitation flow of this vulnerability requires network access to the API endpoint or workflow executor of Flyto2 Core. The attacker begins by setting up an external web server to host a malicious script or configuration payload. This payload acts as the file to be written to the vulnerable server.\n\nNext, the attacker issues a request to the image.download module. In the payload parameters, the attacker overrides the default output directory and destination path, aligning both values to target a sensitive system area. The following diagram details the transaction flow between the components:\n\nmermaid\ngraph LR\n A[\"Attacker Server\"] -->|\"Host Payload\"| B[\"Malicious File\"]\n C[\"Exploit Request\"] -->|\"Parameter Injection\"| D[\"Flyto2 API Engine\"]\n D -->|\"Validation Bypass\"| E[\"Host Filesystem Write\"]\n E -->|\"Create/Overwrite\"| F[\"System Cron / SSH Key\"]\n\n\nWhen the API engine receives the request, it retrieves the payload from the attacker's web server via aiohttp. The validation routine compares the paths and permits the action. The application then writes the retrieved file to the target location on the filesystem. If the process runs with root permissions, this allows overwriting system cron configurations or SSH authorized keys, facilitating immediate remote command execution.

The impact of CVE-2026-67429 represents a severe risk to the host environment due to the arbitrary file write capability. The CVSS score of 10.0 reflects that unauthorized network actors can compromise system integrity without any user interaction. This vulnerability facilitates unauthorized data modification, service disruptions, and total host compromise.\n\nThrough selective writing, an attacker can modify system services or place persistent shells. By writing malicious crontab entries to /etc/cron.d, the attacker executes administrative commands under root context. Alternatively, appending a public key to /root/.ssh/authorized_keys allows direct SSH access to the host machine.\n\nIn automated environments powered by AI agents, this risk is heightened. Since agents execute actions dynamically based on prompt directives, prompt injection vectors can invoke the vulnerable modules indirectly. This enables attacks without direct API interaction, rendering standard network boundary defenses ineffective against malicious workflow instructions.

The primary remediation strategy requires updating the Flyto2 Core library to version 2.26.6 or higher. The update integrates centralized validation across all vulnerable entry points, rendering the parameter override bypass ineffective. Administrators must ensure that the deployment environment defines the FLYTO_SANDBOX_DIR variable to restrict file operations to a dedicated, unprivileged workspace.\n\nIf patching cannot be performed immediately, administrators should run the Flyto2 Core process inside an isolated container with a read-only root file system. This containerization prevents the process from writing outside of explicitly mounted, ephemeral storage volumes. Additionally, the application process should run under a minimally privileged system user account to restrict writing to configuration directories.\n\nFor detection, monitor application logs for anomalous output_dir parameter configurations that point to the root / or system paths. Implement file integrity monitoring on critical filesystems directories to detect unexpected modifications from the application service. Network monitoring should watch for outgoing connection requests from the application to untrusted external hosts during image-handling routines.