CodeAnt AI

Product

Resources

Customers

Enterprise

Pricing

Book a demo

CodeAnt AI

Book a demo

Product

Review, secure and pentest every change, from PR to production.

PRODUCT

AI Pentesting

Black-box and whitebox pentests that prove what is exploitable

AI Code Reviews

Line-by-line reviews on every pull request

Code Security Platform

SAST, SCA, secrets and IaC in one place

Code Quality Platform

Quality gates, coverage and dead code

PLATFORM

IDE

Fix issues before you commit

CLI

Scan from any pipeline

Integrations

GitHub, GitLab, Bitbucket, Jira, Slack

Azure DevOps

Reviews and scans inside ADO

Resources

Docs, research and the team behind CodeAnt AI.

RESOURCES

Documentation

Set up, configure and integrate

Benchmark

How CodeAnt compares on real repos

Security Research

CVEs and disclosures from our team

Blogs

Guides and engineering notes

Vulnerability Database

Search known vulnerabilities

COMPANY

About

The team behind CodeAnt AI

Trust Center

Security, compliance and policies

White Paper

Continuous cyber defense, in depth

Customers

Enterprise

Pricing

Book a demo

Vulnerability database

CVE-2026-67426

Severity:

CRITICAL RISK

(9.3)

SSRF and Secret Exposure (CWE-918) in Flyto2 Core

CVE-2026-67426

Jul 29, 2026

Deferred

Vulnerability type

Category:

Server-Side Request Forgery (SSRF)

CWE:

CWE-306, CWE-522, CWE-918

Impact:

SSRF and Sensitive Information Exposure

Severity:

CRITICAL RISK

(9.3)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Get started

Summary

A flaw in the Flyto2 Core verification service allows unauthenticated callers to trigger outbound HTTP requests to arbitrary callback URLs, sending the internal runner secret header with each request.

When the service is exposed on a network interface without proper access controls, this can enable server-side request forgery (SSRF) and leakage of sensitive secrets to attacker-controlled endpoints.

Affected context

This vulnerability manifests in deployments using the standalone flyto-verification service from src/core/verification_service.py where:

The service listens on 0.0.0.0:8344 (or otherwise reachable externally)
The POST /run endpoint is exposed without authentication or network segmentation
Client-supplied callback_url values are used directly for outbound HTTP callbacks

In such environments, untrusted callers can cause outbound requests to arbitrary URLs and receive internal secret headers.

This vulnerability manifests in deployments using the standalone flyto-verification service from src/core/verification_service.py where:

The service listens on 0.0.0.0:8344 (or otherwise reachable externally)
The POST /run endpoint is exposed without authentication or network segmentation
Client-supplied callback_url values are used directly for outbound HTTP callbacks

In such environments, untrusted callers can cause outbound requests to arbitrary URLs and receive internal secret headers.

Exploit preconditions

Attack surface: HTTP POST /run endpoint on the verification service, listening on 0.0.0.0:8344 or accessible over the network
Required access: Network reachability to the verification service; no authentication or prior trust required
Trigger point: Sending a crafted POST request to /run with a chosen callback_url pointing to an attacker-controlled or internal service
Why exploitation is possible: The service does not enforce authentication (CWE-306) and bypasses target_allowed checks while reusing callback_url for outbound POST requests, including X-Internal-Key: $FLYTO_RUNNER_SECRET (CWE-522, CWE-918)

Attack surface: HTTP POST /run endpoint on the verification service, listening on 0.0.0.0:8344 or accessible over the network
Required access: Network reachability to the verification service; no authentication or prior trust required
Trigger point: Sending a crafted POST request to /run with a chosen callback_url pointing to an attacker-controlled or internal service
Why exploitation is possible: The service does not enforce authentication (CWE-306) and bypasses target_allowed checks while reusing callback_url for outbound POST requests, including X-Internal-Key: $FLYTO_RUNNER_SECRET (CWE-522, CWE-918)

Why this happens

The core issue is the combination of an unauthenticated, externally reachable control endpoint and unvalidated use of client-supplied URLs for server-initiated callbacks.

The verification service trusts the callback_url parameter and performs outbound HTTP requests without validating or constraining the target, mapping directly to CWE-918: Server-Side Request Forgery (SSRF).

Additionally, the service attaches sensitive authentication material (X-Internal-Key with $FLYTO_RUNNER_SECRET) to these requests, exposing secrets to arbitrary destinations (CWE-522), and fails to require authentication or authorization on the /run endpoint (CWE-306).

The core issue is the combination of an unauthenticated, externally reachable control endpoint and unvalidated use of client-supplied URLs for server-initiated callbacks.

Potential impact

Attackers may cause SSRF to internal services that are otherwise not directly reachable from the internet.
Attackers could exfiltrate the runner secret by directing callbacks to attacker-controlled endpoints.
Attackers may pivot deeper into internal infrastructure using the compromised secret.
Attackers could abuse internal APIs, metadata services, or management endpoints via forged requests.
Attackers can disrupt or manipulate automation and AI-agent workflows triggered through the verification service.

Attackers may cause SSRF to internal services that are otherwise not directly reachable from the internet.
Attackers could exfiltrate the runner secret by directing callbacks to attacker-controlled endpoints.
Attackers may pivot deeper into internal infrastructure using the compromised secret.
Attackers could abuse internal APIs, metadata services, or management endpoints via forged requests.
Attackers can disrupt or manipulate automation and AI-agent workflows triggered through the verification service.

General mitigation guidance

Effective mitigation focuses on tightening endpoint access control, constraining callback destinations, and isolating sensitive secrets from untrusted flows.

Recommended patterns include:

Enforcing strong authentication and authorization on control endpoints like /run, ensuring only trusted components can trigger verification runs.
Applying strict allowlists or policy-based validation to any outbound callback URL, restricting targets to known internal services or domains.
Decoupling sensitive secrets from generic callback traffic; avoid sending internal keys to destinations derived from untrusted input.
Segmenting the verification service on internal network interfaces or behind API gateways and service meshes with access controls.
Adopting least-privilege principles for services that hold secrets and reducing their exposure to external inputs.

Effective mitigation focuses on tightening endpoint access control, constraining callback destinations, and isolating sensitive secrets from untrusted flows.

Recommended patterns include:

Enforcing strong authentication and authorization on control endpoints like /run, ensuring only trusted components can trigger verification runs.
Applying strict allowlists or policy-based validation to any outbound callback URL, restricting targets to known internal services or domains.
Decoupling sensitive secrets from generic callback traffic; avoid sending internal keys to destinations derived from untrusted input.
Segmenting the verification service on internal network interfaces or behind API gateways and service meshes with access controls.
Adopting least-privilege principles for services that hold secrets and reducing their exposure to external inputs.

How teams detect issues like this

Organizations can identify and monitor this type of issue through:

Static analysis and code review patterns that flag unauthenticated externally bound endpoints and direct use of user-supplied URLs in outbound requests.
Policy checks that require authentication and authorization on administrative or workflow-triggering endpoints.
Configuration reviews for services listening on 0.0.0.0 and exposing sensitive functionality without gateway-level protection.
Logging and monitoring of outbound HTTP traffic, especially requests carrying internal authentication headers or secrets to untrusted domains.
Periodic security testing focused on SSRF scenarios and secret leakage through callback or webhook mechanisms.

Organizations can identify and monitor this type of issue through:

Static analysis and code review patterns that flag unauthenticated externally bound endpoints and direct use of user-supplied URLs in outbound requests.
Policy checks that require authentication and authorization on administrative or workflow-triggering endpoints.
Configuration reviews for services listening on 0.0.0.0 and exposing sensitive functionality without gateway-level protection.
Logging and monitoring of outbound HTTP traffic, especially requests carrying internal authentication headers or secrets to untrusted domains.
Periodic security testing focused on SSRF scenarios and secret leakage through callback or webhook mechanisms.

Sources

Source	Link
github.com	github.com/flytohub/flyto-core/commit/0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9
github.com	github.com/flytohub/flyto-core/releases/tag/v2.26.7
github.com	github.com/flytohub/flyto-core/security/advisories/GHSA-jx74-cqjv-2c67

Frequently asked

questions

Exploitability depends on how the verification service is deployed. If the service listening on 0.0.0.0:8344 is reachable from the internet or an untrusted network segment, attackers can exploit it remotely; if it is strictly internal and access-controlled, the risk is limited to insiders or compromised services.

An attacker only needs network access to the /run endpoint. No credentials or prior authentication are required, as the endpoint is unauthenticated. They must be able to send HTTP POST requests to the verification service.

The safest pattern is to require strong authentication and authorization on all control-plane endpoints, validate or restrict any client-supplied URLs used for callbacks, and avoid attaching sensitive secrets to requests whose destinations are influenced by untrusted input. Additionally, bind such services to internal interfaces and protect them behind gateways or service meshes.

Future designs should treat callback URLs and webhooks as untrusted data, enforcing allowlists and clear trust boundaries. Services that hold secrets should never send those secrets to destinations derived from user input. Incorporating threat modeling, security-focused code review, static analysis rules for SSRF patterns, and secure network topology (e.g., internal-only bindings and controlled egress) can help prevent similar vulnerabilities.