<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T17:43:27.474747+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-27140</id>
    <title>CVE-2026-27140 — Code execution vulnerability in SWIG code generation in cmd/go</title>
    <updated>2026-10-07T17:43:27.515536+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go toolchain cmd/go, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 8, 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, Red Hat Enterprise Linux 8.8 Telecommunications Update Service and 16 more</p>
<p>SWIG file names containing 'cgo' and well-crafted payloads could lead to code smuggling and arbitrary code execution at build time due to trust layer bypass.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-27140"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-pc3f-x583-g7j2</id>
    <title>GHSA-pc3f-x583-g7j2 — SpdyStream: DOS on CRI</title>
    <updated>2026-10-07T17:43:27.515947+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/moby/spdystream</p>
<p>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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-pc3f-x583-g7j2"/>
  </entry>
</feed>
