CVE-2026-67428: Flyto2 Core SSRF Vulnerability

CVE-2026-67428 Overview

CVE-2026-67428 is a Server-Side Request Forgery (SSRF) vulnerability in Flyto2 Core, an execution kernel for automation and AI-agent workflows. Versions prior to 2.26.7 accept caller-controlled URLs across a broad set of HTTP-emitting modules without invoking validate_url_with_env_config. An authenticated attacker can direct outbound requests to internal services or cloud metadata endpoints, exposing credentials and internal APIs. The issue is fixed in version 2.26.7 and is tracked as [CWE-918].

Critical Impact
Authenticated attackers can pivot Flyto2 Core modules to reach internal network services and cloud instance metadata endpoints, enabling credential theft and lateral movement.

Affected Products

Flyto2 Core versions prior to 2.26.7
Deployments exposing core.api.http_get, core.api.http_post, graphql.query, graphql.mutation, and monitor.http_check
Deployments using notification and AI modules including communication.slack_send, notification.discord.send_message, notification.slack.send_message, notification.teams.send_message, ai.vision_analyze, verify.visual_diff, browser.proxy_rotate, and the agent/LLM inline base_url branch

Discovery Timeline

2026-07-29 - CVE-2026-67428 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-67428

Vulnerability Analysis

Flyto2 Core exposes multiple modules that issue outbound HTTP requests on behalf of automation workflows and AI agents. In versions prior to 2.26.7, these modules pass caller-supplied URLs directly to the HTTP layer in src/core/modules/third_party/developer/http/requests.py without routing them through the validate_url_with_env_config guard. The affected surface includes generic HTTP callers (core.api.http_get, core.api.http_post), GraphQL clients (graphql.query, graphql.mutation), monitoring (monitor.http_check), chat and notification connectors (communication.slack_send, notification.discord.send_message, notification.slack.send_message, notification.teams.send_message), visual and AI modules (ai.vision_analyze, verify.visual_diff), the browser proxy rotator (browser.proxy_rotate), and the agent and LLM inline base_url branch.

Root Cause

The root cause is a missing per-module SSRF guard. Individual modules never call the central URL validator, so private IP ranges, link-local addresses, and cloud metadata hostnames such as 169.254.169.254 are not rejected before the HTTP request is dispatched. This is a classic [CWE-918] Server-Side Request Forgery pattern where trust in caller input replaces enforced network policy.

Attack Vector

An attacker with the ability to invoke a workflow, agent action, or notification module can supply a URL pointing at internal infrastructure. The Flyto2 Core process, running with backend network reachability, then issues the request and returns response data or side effects to the caller. Targets include cloud instance metadata services, internal admin panels, service meshes, and unauthenticated internal APIs.

python

# Patch excerpt: src/core/modules/atomic/ai/vision_analyze.py
 from ...errors import ModuleError, ValidationError
 from ...registry import register_module
 from ...schema import compose, field
+from ....utils import enforce_outbound_url, SSRFError
 
 logger = logging.getLogger(__name__)

# Patch excerpt: src/core/modules/atomic/browser/proxy_rotate.py
 from ...base import BaseModule
 from ...registry import register_module
 from ...schema import compose, field
+from ....utils import enforce_outbound_url, SSRFError
 
 logger = logging.getLogger(__name__)
# Source: https://github.com/flytohub/flyto-core/commit/0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9

The patch introduces enforce_outbound_url and SSRFError imports into each affected module, wiring in the previously missing per-module guard.

Detection Methods for CVE-2026-67428

Indicators of Compromise

Outbound HTTP requests from the Flyto2 Core process to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that are not part of normal workflow destinations
Requests to cloud metadata endpoints such as 169.254.169.254, metadata.google.internal, or 100.100.100.200
Unexpected values in module parameters such as base_url, proxy, url, or endpoint referencing loopback or link-local hosts
Workflow logs showing core.api.http_get, graphql.query, or notification modules resolving to internal hostnames

Detection Strategies

Instrument egress network telemetry to flag Flyto2 Core connections to private, loopback, and link-local IP ranges
Audit workflow definitions and agent prompts for user-controllable URL fields feeding into the modules listed in the advisory
Correlate Flyto2 Core module invocations with subsequent access to cloud IAM credentials or short-lived tokens

Monitoring Recommendations

Forward Flyto2 Core application logs and outbound HTTP proxy logs to a central analytics tier for URL destination analysis
Alert on any response containing IMDS token headers (X-aws-ec2-metadata-token) or metadata JSON structures returned to a workflow context
Track version banners on Flyto2 Core deployments to identify hosts still running builds prior to 2.26.7

How to Mitigate CVE-2026-67428

Immediate Actions Required

Upgrade Flyto2 Core to version 2.26.7 or later, which adds the per-module enforce_outbound_url guard
Restrict who can author or execute workflows that invoke HTTP-emitting modules, especially agent and llm flows with inline base_url
Block Flyto2 Core hosts from reaching cloud metadata endpoints at the network layer until the upgrade is complete

Patch Information

The fix is available in GitHub Release v2.26.7. The remediation commit is 0a0a5285, and full details are documented in GHSA-pgwh-4jj4-qm8v.

Workarounds

Enforce IMDSv2 with hop-limit 1 on AWS instances hosting Flyto2 Core to raise the bar against metadata SSRF
Deploy an egress proxy or firewall policy that denies Flyto2 Core outbound traffic to 169.254.0.0/16 and RFC1918 destinations not required by workflows
Disable or gate the affected modules (ai.vision_analyze, browser.proxy_rotate, notification connectors, agent/LLM base_url) until the upgrade is applied

bash

# Example iptables egress restriction for Flyto2 Core host
iptables -A OUTPUT -m owner --uid-owner flyto -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 192.168.0.0/16 -j REJECT