CVE-2026-67425: Flyto2 Core SSRF Vulnerability

CVE-2026-67425 Overview

CVE-2026-67425 is a credential exposure vulnerability in Flyto2 Core, an execution kernel for automation and AI-agent workflows. In versions prior to 2.26.6, the llm.chat module reads provider keys such as OPENAI_API_KEY and ANTHROPIC_API_KEY from the host environment. It then sends those keys in the Authorization: Bearer header to a caller-controlled base_url. An attacker who supplies a public host that passes the built-in Server-Side Request Forgery (SSRF) guard receives the operator's provider key directly. The issue is tracked under [CWE-201: Insertion of Sensitive Information Into Sent Data] and is fixed in Flyto2 Core 2.26.6.

Critical Impact
Unauthenticated network attackers can exfiltrate operator LLM provider API keys by directing llm.chat to a public server they control.

Affected Products

Flyto2 Core versions prior to 2.26.6
Workflows invoking the llm.chat module with untrusted base_url inputs
Deployments exposing OPENAI_API_KEY, ANTHROPIC_API_KEY, or similar provider credentials via environment variables

Discovery Timeline

2026-07-29 - CVE-2026-67425 published to NVD
2026-07-29 - Last updated in NVD database
Fix released - Flyto2 Core v2.26.6 published on GitHub with GHSA-qq9q-xgm3-xv9g

Technical Details for CVE-2026-67425

Vulnerability Analysis

Flyto2 Core executes automation and AI-agent workflows and exposes an llm.chat module for invoking large language model providers. The module accepts a base_url parameter from the workflow caller so operators can target OpenAI, Anthropic, or compatible endpoints. When constructing the outbound request, llm.chat reads provider secrets from environment variables and attaches them as Authorization: Bearer headers. The engine also performs variable interpolation using ${env.VAR} expressions before module policies are applied, which broadens exposure of environment secrets beyond the env.get denylist.

The base_url value passes through an SSRF guard designed to block internal or loopback destinations. That guard does not restrict outbound requests to trusted LLM providers, so any publicly routable attacker-controlled host is accepted. Every request to such a host carries the operator's provider credential, resulting in direct credential disclosure to a third party.

Root Cause

The root cause is missing binding between environment-sourced credentials and trusted endpoints. Credentials are attached to any host that satisfies the SSRF guard rather than a validated allowlist of provider domains. In addition, engine-level ${env.*} interpolation runs before the module chokepoint, so denylisting env.get alone cannot stop secret exfiltration through workflow parameters.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker who can submit or influence a workflow supplies a base_url pointing to a public host they control. The Flyto2 Core engine expands ${env.*} references, attaches the provider key as a bearer token, and dispatches the HTTPS request. The attacker's server logs the Authorization header and captures the operator's API key.

python

# Security patch in 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. 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 a deny-by-default policy for ${env.*} interpolation and requires operators to opt in through FLYTO_ENV_VAR_ALLOWLIST. It also binds environment-sourced credentials to trusted endpoints so that Authorization: Bearer headers no longer flow to arbitrary hosts.

Detection Methods for CVE-2026-67425

Indicators of Compromise

Outbound HTTPS connections from Flyto2 Core hosts to unfamiliar or newly registered domains carrying Authorization: Bearer headers
Workflow definitions containing llm.chat steps with a base_url that does not match api.openai.com, api.anthropic.com, or other approved providers
Presence of ${env.OPENAI_API_KEY}, ${env.ANTHROPIC_API_KEY}, or similar interpolation tokens in stored workflow files
Provider-side alerts for API key usage from unexpected source IP ranges or geographies

Detection Strategies

Inspect Flyto2 Core workflow history and audit logs for base_url values pointing outside your organization's approved LLM provider domain list
Correlate process telemetry from Flyto2 Core hosts with DNS and HTTPS destinations to flag first-seen or low-reputation domains
Rotate provider keys and search LLM provider audit logs for calls originating from IPs not associated with your infrastructure

Monitoring Recommendations

Forward Flyto2 Core application logs and host network telemetry to a centralized data lake for retention and correlation
Alert on any llm.chat invocation where the resolved base_url host is not on an approved allowlist
Monitor for creation or modification of FLYTO_ENV_VAR_ALLOWLIST and related environment configuration on production hosts

How to Mitigate CVE-2026-67425

Immediate Actions Required

Upgrade Flyto2 Core to version 2.26.6 or later on all hosts running the execution kernel
Rotate every LLM provider API key that was reachable through ${env.*} on affected systems, including OPENAI_API_KEY and ANTHROPIC_API_KEY
Audit workflow repositories for llm.chat steps with attacker-influenceable base_url values and remove or restrict them
Review provider-side audit logs for anomalous key usage during the exposure window

Patch Information

The fix is delivered in Flyto2 Core v2.26.6. Refer to the GitHub Release v2.26.6, the security-hardening commit d5f89d7, and the GitHub Security Advisory GHSA-qq9q-xgm3-xv9g. The patch confines writes, gates ${env.*} interpolation, and binds environment credentials to trusted endpoints.

Workarounds

Restrict which environment variables are readable by workflows using FLYTO_ENV_VAR_ALLOWLIST with an explicit, minimal set of names
Enforce an outbound egress allowlist on Flyto2 Core hosts so llm.chat can only reach approved LLM provider domains
Remove long-lived provider keys from the Flyto2 Core host environment and inject short-lived, per-request credentials from a secrets broker instead

bash

# Configuration example: deny-by-default env interpolation after upgrading to 2.26.6
export FLYTO_ENV_VAR_ALLOWLIST="PUBLIC_*,APP_REGION"

# Do NOT include provider secrets in the allowlist:
#   OPENAI_API_KEY, ANTHROPIC_API_KEY, and similar values must be brokered
#   through a trusted credential service, not exposed via ${env.*}.