CVE-2026-67427: Flyto2 Core Information Disclosure Flaw

CVE-2026-67427 Overview

CVE-2026-67427 is a credential exposure vulnerability in Flyto2 Core, an execution kernel for automation and AI-agent workflows. The workflow engine variable resolver expands ${env.VAR} for any host environment variable without an allowlist or capability policy check. This allows a workflow parameter to bypass the default capability policy denylist for env.get and env.load_dotenv. Attackers can exfiltrate secrets through modules that remain permitted by policy. The issue is tracked under [CWE-522: Insufficiently Protected Credentials] and is fixed in Flyto2 Core version 2.26.6.

Critical Impact
Remote attackers can exfiltrate host environment secrets, including API keys and tokens, by injecting ${env.VAR} references into workflow parameters, bypassing the module denylist entirely.

Affected Products

Flyto2 Core versions prior to 2.26.6
Automation pipelines running the Flyto2 workflow engine
AI-agent workflows dependent on Flyto2 Core variable resolution

Discovery Timeline

2026-07-29 - CVE-2026-67427 published to NVD
2026-07-29 - Last updated in NVD database
v2.26.6 - Vendor releases patched version with gated ${env.*} interpolation

Technical Details for CVE-2026-67427

Vulnerability Analysis

The Flyto2 Core workflow engine performs variable interpolation on step parameters before passing them to modules. When a workflow parameter contains ${env.VAR}, the engine's VariableResolver reads the host environment variable directly and substitutes its value. This interpolation runs in the engine, not through the module execution pipeline. Consequently, the capability policy that denylists env.get and env.load_dotenv is never consulted during interpolation.

An attacker who controls workflow parameters can reference any process environment variable. Because the resolved value becomes a string parameter to a downstream allowed module, secrets can be forwarded to network destinations through modules such as HTTP requesters or loggers. The denylist offers no protection, since the sensitive read happens upstream of the module chokepoint.

Root Cause

The root cause is a policy enforcement gap between the variable resolver and the module capability filter. The engine treats ${env.*} expansion as an internal templating feature rather than a privileged capability. The GitHub Security Advisory GHSA-hr7p-wg7r-hg9m documents that interpolation happens before the module chokepoint, so denylisting env.get alone does not stop the read.

Attack Vector

Exploitation requires the ability to submit or influence a workflow definition. A malicious workflow parameter such as ${env.AWS_SECRET_ACCESS_KEY} resolves to the live host secret. The resolved value is then passed to a permitted module (for example, an outbound HTTP call) that exfiltrates it. No authentication is required in default configurations exposed over the network.

python

# Patched policy logic from src/core/module_policy.py
# Source: https://github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc

# The workflow engine expands ${env.VAR} in step parameters. That is the exact
# capability the `env.get` module denylist exists to block (reading arbitrary
# host env vars = secret exfil). Interpolation happens in the engine BEFORE the
# module chokepoint, so denylisting `env.get` alone does not stop it
# (GHSA-hr7p-wg7r-hg9m). We therefore gate ${env.*} through one shared policy:
#
#   - If `env.get` is permitted by the module filter, env access is enabled and
#     ${env.VAR} resolves as before.
#   - Otherwise (the secure default), ${env.VAR} is DENIED unless VAR matches an
#     explicit allowlist the operator opts into via FLYTO_ENV_VAR_ALLOWLIST
#     (comma-separated names or fnmatch globs, e.g. "PUBLIC_*,APP_REGION").

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."""

The patch introduces is_env_var_allowed() and an operator-controlled FLYTO_ENV_VAR_ALLOWLIST, enforcing deny-by-default interpolation.

Detection Methods for CVE-2026-67427

Indicators of Compromise

Workflow definitions or step parameters containing ${env.*} references to sensitive variables such as AWS_*, GITHUB_TOKEN, OPENAI_API_KEY, or *_SECRET.
Outbound network calls from Flyto2 Core processes to unexpected destinations shortly after workflow execution.
Log entries from allowed modules containing values that match the shape of API tokens or credentials.

Detection Strategies

Audit stored workflow definitions and pull requests for ${env. substrings and flag any references outside a known-safe allowlist.
Correlate Flyto2 Core process telemetry with DNS and HTTP egress to identify data flows from workflow executions to external endpoints.
Monitor changes to Flyto2 Core versions and confirm all instances report version 2.26.6 or later.

Monitoring Recommendations

Enable verbose engine logging for variable resolution events and forward logs to a centralized platform for retention and search.
Alert on any workflow submission that references environment variables not present in FLYTO_ENV_VAR_ALLOWLIST.
Track outbound connections initiated by the Flyto2 Core service account to detect exfiltration attempts.

How to Mitigate CVE-2026-67427

Immediate Actions Required

Upgrade Flyto2 Core to version 2.26.6 or later, available at GitHub Release v2.26.6.
Rotate any secrets held in environment variables accessible to the Flyto2 Core process, including cloud credentials, tokens, and database passwords.
Review workflow definitions submitted since deployment for ${env.*} references indicating attempted or successful exploitation.

Patch Information

The fix is delivered in the security commit d5f89d7 and released as version 2.26.6. The patch gates ${env.*} interpolation behind the module capability policy and adds a FLYTO_ENV_VAR_ALLOWLIST operator control. Interpolation is now denied by default unless the variable name matches an explicit allowlist entry.

Workarounds

Restrict the Flyto2 Core process environment to a minimal set of non-sensitive variables and store secrets in a dedicated secret manager retrieved at runtime.
Place the workflow engine behind authenticated network controls to limit who can submit or modify workflow definitions.
Apply egress filtering to the Flyto2 Core host to prevent outbound connections to arbitrary destinations.

bash

# After upgrading to 2.26.6, define an explicit allowlist for interpolation.
# Only variables matching these names or fnmatch globs will resolve via ${env.*}.
export FLYTO_ENV_VAR_ALLOWLIST="PUBLIC_*,APP_REGION,APP_ENV"

# Verify installed version
flyto --version   # should report 2.26.6 or later