Flyto Core CVE-2026-67426

Exploitation requires only that the standalone flyto-verification service (src/core/verification_service.py) is running and its POST /run listener on 0.0.0.0:8344 is network-reachable by the attacker; the endpoint is unauthenticated (PR:N) and needs no user interaction. The concrete attacker-controlled input is the callback_url field, which the service uses for an outbound POST while bypassing the target_allowed allowlist and attaching the X-Internal-Key: $FLYTO_RUNNER_SECRET header. Limiting factors: only deployments running that standalone verification service on an interface exposed to untrusted networks are exploitable - if 8344 is bound to loopback or firewalled to trusted hosts, or the verification service is not deployed, remote exploitation does not apply. Affected only on versions prior to 2.26.7.

This is a genuine high priority, not a paper tiger. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N, 9.3) describes a network-reachable, low-complexity, unauthenticated attack with no user interaction and a scope change, which is fully consistent with the description of an open port accepting anonymous requests. The scope change and C:H reflect that the leaked runner secret and internal SSRF reach systems beyond the vulnerable service itself. No EPSS score, KEV entry, or SSVC decision data was supplied, and no public proof-of-concept was identified, so likelihood signals beyond the CVSS vector are unavailable - absence of EPSS/KEV should not be read as low risk given the trivial exploitability. The main mitigating real-world factor is deployment prevalence: this depends on whether the standalone verification service is actually exposed to untrusted networks rather than bound to a trusted internal segment. Note the outbound header leak makes secret theft a near-certain consequence, elevating this above a pure blind-SSRF issue.

An attacker who can reach TCP 8344 sends an unauthenticated POST /run to the flyto-verification service with a callback_url pointing at a server they control. The service performs an outbound POST to that URL including the X-Internal-Key header containing FLYTO_RUNNER_SECRET, handing the attacker the runner secret; alternatively the attacker points callback_url at an internal address (e.g. a cloud metadata service or internal API) to perform blind SSRF against otherwise unreachable systems. No credentials, exploit code, or user interaction are required given the low attack complexity.