https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 07:42:10 +0000 https://cve.radiocsirt.org/vuln/cve-2026-1605 <p><strong>Affected:</strong> Eclipse Foundation Eclipse Jetty, Red Hat HawtIO HawtIO 4.4.0, Red Hat AMQ Broker 7.14.0, Red Hat JBoss Enterprise Application Platform 8.1, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 8, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 9, Red Hat OpenShift Developer Tools and Services 4.12, Red Hat OpenShift Developer Tools and Services 4.13, Red Hat OpenShift Developer Tools and Services 4.14, Red Hat OpenShift Developer Tools and Services 4.15 and 28 more</p> <p>In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed.</p> <p>This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.</p> <p><strong>Affected:</strong> Eclipse Foundation Eclipse Jetty, Red Hat HawtIO HawtIO 4.4.0, Red Hat AMQ Broker 7.14.0, Red Hat JBoss Enterprise Application Platform 8.1, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 8, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 9, Red Hat OpenShift Developer Tools and Services 4.12, Red Hat OpenShift Developer Tools and Services 4.13, Red Hat OpenShift Developer Tools and Services 4.14, Red Hat OpenShift Developer Tools and Services 4.15 and 28 more</p> <p>In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed.</p> <p>This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.</p> https://cve.radiocsirt.org/vuln/cve-2026-1605 https://cve.radiocsirt.org/vuln/ghsa-3677-xxcr-wjqv <p><strong>Affected:</strong> Maven: org.bitbucket.b_c:jose4j</p> <p>In jose4j before 0.9.6, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.</p> <p><strong>Affected:</strong> Maven: org.bitbucket.b_c:jose4j</p> <p>In jose4j before 0.9.6, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.</p> https://cve.radiocsirt.org/vuln/ghsa-3677-xxcr-wjqv