<?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://vulnerability.circl.lu</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>Wed, 07 Oct 2026 02:30:43 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-61732 — Potential code smuggling via doc comments in cmd/cgo</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-61732</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go toolchain cmd/cgo, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Telecommunications Update Service, Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions and 23 more&lt;/p&gt;
&lt;p&gt;A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go toolchain cmd/cgo, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Telecommunications Update Service, Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions and 23 more&lt;/p&gt;
&lt;p&gt;A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-61732</guid>
    </item>
    <item>
      <title>GHSA-pc3f-x583-g7j2 — SpdyStream: DOS on CRI</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-pc3f-x583-g7j2</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/moby/spdystream&lt;/p&gt;
&lt;p&gt;The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:
1. **SETTINGS entry count** -- The SETTINGS frame reader reads a 32-bit
`numSettings` from the payload and allocates a slice of that size
without checking it against the declared frame length. An attacker
can set `numSettings` to a value far exceeding the actual payload,
triggering a large allocation before any setting data is read.
 
2. **Header count** -- `parseHeaderValueBlock` reads a 32-bit
`numHeaders` from the decompressed header block and allocates an
`http.Header` map of that size with no upper bound.
 
3. **Header field size** -- Individual header name and value lengths are
read as 32-bit integers and used directly as allocation sizes with
no validation.
 
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.
## Impact
 Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/moby/spdystream&lt;/p&gt;
&lt;p&gt;The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:
1. **SETTINGS entry count** -- The SETTINGS frame reader reads a 32-bit
`numSettings` from the payload and allocates a slice of that size
without checking it against the declared frame length. An attacker
can set `numSettings` to a value far exceeding the actual payload,
triggering a large allocation before any setting data is read.
 
2. **Header count** -- `parseHeaderValueBlock` reads a 32-bit
`numHeaders` from the decompressed header block and allocates an
`http.Header` map of that size with no upper bound.
 
3. **Header field size** -- Individual header name and value lengths are
read as 32-bit integers and used directly as allocation sizes with
no validation.
 
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.
## Impact
 Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-pc3f-x583-g7j2</guid>
    </item>
  </channel>
</rss>
