https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 22:01:39 +0000 https://cve.radiocsirt.org/vuln/cleanstart-2026-lj83599 <p><strong>Affected:</strong> CleanStart: hazelcast, CleanStart: logstash-fips, CleanStart: strimzi-kafka-operator</p> <p>ghsa-q4f6-jm68-57ww affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: hazelcast, CleanStart: logstash-fips, CleanStart: strimzi-kafka-operator</p> <p>ghsa-q4f6-jm68-57ww affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-lj83599 https://cve.radiocsirt.org/vuln/cve-2026-59899 <p><strong>Affected:</strong> netty</p> <p>Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, `HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque&lt;CharSequence&gt;` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.</p> <p><strong>Affected:</strong> netty</p> <p>Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, `HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque&lt;CharSequence&gt;` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.</p> https://cve.radiocsirt.org/vuln/cve-2026-59899