Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidationGHSA-c9hr-64h3-gxpc

HIGHFix: flytohub/flyto-core@0a0a528

GHSA-c9hr-64h3-gxpc is a high-severity (CVSS 8.5) Server-Side Request Forgery (SSRF) vulnerability in flyto-core. A fix is available for flyto-core — see the affected versions and patch details below.

Also known asCVE-2026-67424PYSEC-2026-3569
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 25, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-c9hr-64h3-gxpc.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk-0.12%
Lower risk than most CVEs22th percentile — riskier than 22% of all scored CVEsHighest risk
0.00%0.30%0.61%0.91%0.2%0.2%0.4%0.3%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-c9hr-64h3-gxpc by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍flyto-core

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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

  1. 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 on attacker.tld (public) → passes; never re-run on the redirect target.
  2. Sink: 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.
  3. 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).

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIflyto-coreall versions2.26.7pip install --upgrade 'flyto-core==2.26.7'

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flyto-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update flyto-core to 2.26.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c9hr-64h3-gxpc is resolved across your whole dependency graph.

  3. Workarounds

    Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

## 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.
O3 Security · Impact-Aware SCA

Is GHSA-c9hr-64h3-gxpc in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
Flyto2 Core: Guarded HTTP modules follow redirects into…