<?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://cve.radiocsirt.org</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>Sun, 04 Oct 2026 23:33:36 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-7598 — Network restriction bypass via race condition during namespace termination</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-7598</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Kubernetes kube-apiserver&lt;/p&gt;
&lt;p&gt;A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Kubernetes kube-apiserver&lt;/p&gt;
&lt;p&gt;A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-7598</guid>
    </item>
    <item>
      <title>GHSA-2wpx-qpw2-g5h5 — CoreDNS' DoQ worker pool does not bound stream backlog</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2wpx-qpw2-g5h5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/coredns/coredns&lt;/p&gt;
&lt;p&gt;### Summary
CoreDNS&amp;#39; DNS-over-QUIC (DoQ) server can be driven into large goroutine and memory growth by a remote client that opens many QUIC streams and stalls after sending only 1 byte. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill.&lt;/p&gt;
&lt;p&gt;### Details
CoreDNS&amp;#39; DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool &amp;lt;- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go)&lt;/p&gt;
&lt;p&gt;Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go)&lt;/p&gt;
&lt;p&gt;This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token.&lt;/p&gt;
&lt;p&gt;Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw).&lt;/p&gt;
&lt;p&gt;### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tu…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/coredns/coredns&lt;/p&gt;
&lt;p&gt;### Summary
CoreDNS&amp;#39; DNS-over-QUIC (DoQ) server can be driven into large goroutine and memory growth by a remote client that opens many QUIC streams and stalls after sending only 1 byte. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill.&lt;/p&gt;
&lt;p&gt;### Details
CoreDNS&amp;#39; DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool &amp;lt;- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go)&lt;/p&gt;
&lt;p&gt;Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go)&lt;/p&gt;
&lt;p&gt;This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token.&lt;/p&gt;
&lt;p&gt;Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw).&lt;/p&gt;
&lt;p&gt;### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2wpx-qpw2-g5h5</guid>
    </item>
  </channel>
</rss>
