<?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-09-30T15:22:43.097339+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-48006</id>
    <title>CVE-2026-48006 — Netty's Lack of Lifecycle Cleanup Leads to Pooled ByteBuf Leak in RedisArrayAggregator</title>
    <updated>2026-09-30T15:22:43.099176+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> netty, Red Hat build of Apache Camel 4.18.1.P1 for Spring Boot 3.5.16, 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, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 9, Red Hat JBoss Enterprise Application Platform 8.1, Red Hat Fuse 7, Red Hat JBoss Enterprise Application Platform Expansion Pack, Red Hat Single Sign-On 7</p>
<p>Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-48006"/>
  </entry>
</feed>
