https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 23:23:54 +0000 https://vulnerability.circl.lu/vuln/cve-2026-48043 <p><strong>Affected:</strong> netty, Red Hat Cryostat 4 on RHEL 9, Red Hat AMQ Broker 7.14.1, Red Hat Build of Apache Camel 3.33 for Quarkus 3.33.2.SP1, Red Hat build of Apache Camel 4.18.1.P1 for Spring Boot 3.5.16, Red Hat build of Quarkus 3.27.4.SP1, Red Hat build of Quarkus 3.33.2.SP1, Red Hat Data Grid 8.6.2, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 7, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 8 and 17 more</p> <p>Netty is a network application framework for development of protocol servers and clients. In netty-codec-http2 prior to versions 4.1.135.Final and 4.2.15.Final, the `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue.</p> <p><strong>Affected:</strong> netty, Red Hat Cryostat 4 on RHEL 9, Red Hat AMQ Broker 7.14.1, Red Hat Build of Apache Camel 3.33 for Quarkus 3.33.2.SP1, Red Hat build of Apache Camel 4.18.1.P1 for Spring Boot 3.5.16, Red Hat build of Quarkus 3.27.4.SP1, Red Hat build of Quarkus 3.33.2.SP1, Red Hat Data Grid 8.6.2, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 7, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 8 and 17 more</p> <p>Netty is a network application framework for development of protocol servers and clients. In netty-codec-http2 prior to versions 4.1.135.Final and 4.2.15.Final, the `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue.</p> https://vulnerability.circl.lu/vuln/cve-2026-48043 https://vulnerability.circl.lu/vuln/ghsa-c2gf-v879-257j <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http2</p> <p>### Impact</p> <p>The `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it.</p> <p>A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME.</p> <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http2</p> <p>### Impact</p> <p>The `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it.</p> <p>A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME.</p> https://vulnerability.circl.lu/vuln/ghsa-c2gf-v879-257j