<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 08:10:19 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-67424 — Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation</title>
      <link>https://db.gcve.eu/vuln/cve-2026-67424</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; flytohub flyto-core&lt;/p&gt;
&lt;p&gt;Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the HTTP modules http.get, http.request, and http.batch in src/core/modules/atomic/http/get.py, src/core/modules/atomic/http/request.py, and src/core/modules/atomic/http/batch.py validate only the initial URL, then follow redirects with allow_redirects=True and without per-hop Location revalidation, allowing a public URL to redirect into internal address space and return the internal response body. This issue is fixed in version 2.26.7.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; flytohub flyto-core&lt;/p&gt;
&lt;p&gt;Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the HTTP modules http.get, http.request, and http.batch in src/core/modules/atomic/http/get.py, src/core/modules/atomic/http/request.py, and src/core/modules/atomic/http/batch.py validate only the initial URL, then follow redirects with allow_redirects=True and without per-hop Location revalidation, allowing a public URL to redirect into internal address space and return the internal response body. This issue is fixed in version 2.26.7.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-67424</guid>
    </item>
    <item>
      <title>GHSA-c9hr-64h3-gxpc — Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation</title>
      <link>https://db.gcve.eu/vuln/ghsa-c9hr-64h3-gxpc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flyto-core&lt;/p&gt;
&lt;p&gt;## 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## 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.&lt;/p&gt;
&lt;p&gt;## 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.&lt;/p&gt;
&lt;p&gt;## 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  -&amp;gt;  302 Location: http://&amp;lt;cloud-metadata-ip&amp;gt;/latest/meta-data/...
execute_module http.get {&amp;#34;url&amp;#34;:&amp;#34;http://attacker.tld/r&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;## Attack Chain
1. Entry: `execute_module http.get {url:&amp;#34;http://attacker.tld/r&amp;#34;}` (attacker 302-&amp;gt;internal). Guard: `validate_url_with…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flyto-core&lt;/p&gt;
&lt;p&gt;## 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## 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.&lt;/p&gt;
&lt;p&gt;## 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.&lt;/p&gt;
&lt;p&gt;## 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  -&amp;gt;  302 Location: http://&amp;lt;cloud-metadata-ip&amp;gt;/latest/meta-data/...
execute_module http.get {&amp;#34;url&amp;#34;:&amp;#34;http://attacker.tld/r&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;## Attack Chain
1. Entry: `execute_module http.get {url:&amp;#34;http://attacker.tld/r&amp;#34;}` (attacker 302-&amp;gt;internal). Guard: `validate_url_with…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-c9hr-64h3-gxpc</guid>
    </item>
  </channel>
</rss>
