CVE-2026-67429: Flyto2 Core Path Traversal Vulnerability

CVE-2026-67429 Overview

CVE-2026-67429 is a path traversal vulnerability [CWE-22] in Flyto2 Core, an execution kernel for automation and AI-agent workflows. Prior to version 2.26.6, the image.download module and related file-writing modules accept a caller-controlled output_dir parameter. The engine bypasses the validate_path_with_env_config helper and the FLYTO_SANDBOX_DIR confinement boundary. Attacker-controlled response bytes can be written to arbitrary filesystem paths accessible to the process. The issue affects workflow steps that fetch remote content and persist it to disk. Version 2.26.6 introduces enforced sandbox-directory validation across all write paths.

Critical Impact
Unauthenticated network attackers can write arbitrary bytes to any path the Flyto2 Core process can access, enabling code execution through overwrite of workflow scripts, configuration files, or startup artifacts.

Affected Products

Flyto2 Core (flytohub/flyto-core) versions prior to 2.26.6
Automation workflows invoking image.download and related file-writing modules
Deployments that do not enforce FLYTO_SANDBOX_DIR at the module boundary

Discovery Timeline

2026-07-29 - CVE-2026-67429 published to the National Vulnerability Database (NVD)
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-67429

Vulnerability Analysis

Flyto2 Core executes user-authored workflow steps that resolve variables and invoke modules such as image.download. The download module writes the fetched HTTP response body to a filesystem location constructed from a caller-supplied output_dir parameter. In vulnerable releases the module skips the validate_path_with_env_config guard, which is intended to confine writes to the FLYTO_SANDBOX_DIR root. Because no canonicalization or prefix check occurs, values containing ../ sequences or absolute paths resolve outside the sandbox.

An attacker who can submit or influence a workflow definition can direct writes to arbitrary paths. When the process runs as a privileged user, the impact extends to overwrite of system binaries, cron entries, SSH authorized_keys, or workflow definition files loaded on the next execution cycle.

Root Cause

The root cause is missing path validation on the module-side write sink. The engine trusted caller-supplied output paths and did not route them through the sandbox validator. The fix in commit d5f89d7 introduces confined writes, gates ${env.*} interpolation through a shared policy, and binds environment credentials to trusted endpoints.

Attack Vector

Exploitation requires no authentication and no user interaction when a workflow accepts remote input. An attacker crafts a workflow step or API payload that sets output_dir to a traversal string and points the download URL at attacker-controlled content. The module writes the response bytes to the attacker-chosen path.

python

# Security patch excerpt from src/core/module_policy.py
# Source: https://github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc

# ---------------------------------------------------------------------------
# Environment-variable interpolation policy
# ---------------------------------------------------------------------------
# The workflow engine expands ${env.VAR} in step parameters. Interpolation
# happens in the engine BEFORE the module chokepoint, so denylisting env.get
# alone does not stop it. We therefore gate ${env.*} through one shared policy:
#   - If env.get is permitted by the module filter, ${env.VAR} resolves.
#   - Otherwise (secure default), ${env.VAR} is DENIED unless VAR matches
#     FLYTO_ENV_VAR_ALLOWLIST (comma-separated names or fnmatch globs).

def _env_var_allowlist() -> List[str]:
    raw = os.environ.get("FLYTO_ENV_VAR_ALLOWLIST", "")
    return [p.strip() for p in raw.split(",") if p.strip()]


def is_env_var_allowed(name: str) -> bool:
    """Whether ${env.<name>} interpolation is permitted by policy."""

Source: GitHub Commit d5f89d7

Detection Methods for CVE-2026-67429

Indicators of Compromise

File writes by the Flyto2 Core process to paths outside the configured FLYTO_SANDBOX_DIR root
Workflow step parameters containing ../, absolute paths, or URL-encoded traversal sequences in output_dir
Unexpected modifications to startup scripts, cron jobs, or SSH key files on hosts running Flyto2 Core
Outbound HTTP fetches from image.download to unfamiliar remote hosts followed by local file creation

Detection Strategies

Audit workflow definitions and API requests for output_dir values that resolve outside the sandbox root after canonicalization
Correlate process telemetry linking the Flyto2 Core parent process to file writes in sensitive directories
Alert on any image.download invocation whose target path prefix does not match FLYTO_SANDBOX_DIR

Monitoring Recommendations

Enable filesystem auditing on directories containing executable scripts, configuration files, and identity material
Log every module invocation with resolved output path and originating workflow identifier
Track version drift and flag hosts still running Flyto2 Core builds earlier than 2.26.6

How to Mitigate CVE-2026-67429

Immediate Actions Required

Upgrade Flyto2 Core to version 2.26.6 or later on all execution hosts
Set and enforce FLYTO_SANDBOX_DIR to a dedicated, non-privileged directory for workflow output
Restrict who can submit or modify workflow definitions to trusted operators only
Run Flyto2 Core under a least-privileged service account with no write access to system directories

Patch Information

The fix is available in Flyto2 Core release v2.26.6. See the GitHub Release v2.26.6, the GitHub Security Advisory GHSA-2956-977x-2w3r, and the remediation commit d5f89d7. The patch routes image.download and related sinks through validate_path_with_env_config, gates ${env.*} interpolation, and binds environment credentials to trusted endpoints.

Workarounds

Disable the image.download module and other caller-controlled file-writing modules until the upgrade is applied
Run the Flyto2 Core process inside a container with a read-only root filesystem and a writable mount only for the sandbox directory
Apply mandatory access controls (AppArmor, SELinux) that constrain the process to the sandbox path

bash

# Configuration example: enforce sandbox confinement and env allowlist
export FLYTO_SANDBOX_DIR=/var/lib/flyto/sandbox
export FLYTO_ENV_VAR_ALLOWLIST="PUBLIC_*,APP_REGION"

install -d -o flyto -g flyto -m 0750 "$FLYTO_SANDBOX_DIR"
pip install --upgrade flyto-core==2.26.6