CVE and update status of the FreeBSD ports tree3,534 unaddressed CVEs in 701 portsAll times are CET
CVE details

CVE-2026-111551

Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.

Score
–
Published
2026-10-28
Links
NVD · cve.org · Report wrong data

Matched ports (1)

PortPackageVersionStatusMaintainer
net/kafkakafka4.3.1unaddressedtimp87@gmail.com

Template for a VuXML entry

This generator is not reliable at the moment

Package names, ranges and the XML itself can be wrong. Always check the content before you commit it, and run make validate in security/vuxml. The generator is being rewritten from scratch.

Range per package from the CVE record, for ports with a version line in their name (python312) only from that line. make newentry in security/vuxml creates the vid.

  <vuln vid="FIXME (make newentry)">
    <topic>FIXME -- FIXME</topic>
    <affects>
      <package>
	<name>kafka</name>
	<!-- no fixed version in the CVE record -->
	<range><lt>FIXME</lt></range>
      </package>
    </affects>
    <description>
      <body xmlns="http://www.w3.org/1999/xhtml">
	<p>Several Kafka deserialization paths read a size or count field from
	  input data and use it directly to allocate an array, collection, or
	  byte buffer, with no check against the bytes actually available. A
	  small crafted input can therefore declare a very large size and force
	  a multi-gigabyte allocation. The affected paths are, in Kafka Streams,
	  ProcessorRecordContext (header count), ChangedDeserializer (varint
	  value length), CombinedKeySchema (foreign-key length, which could also
	  produce a negative size), ProcessorMetadata (key length), and
	  AssignmentInfo group-assignment decoding; and, in the clients library,
	  ListDeserializer (used by ListSerde).</p>
	<p>Impact:</p>
	<p>An attacker can trigger the oversized allocation and raise an
	  OutOfMemoryError that crashes the affected consumer or Kafka Streams
	  thread; the broker and the rest of the cluster are unaffected. The
	  reachable surface depends on the path: writing a crafted record to a
	  Streams application's internal changelog or repartition topics, or
	  committing crafted offset metadata to its consumer group (Streams
	  internal paths); writing a crafted record to any topic that a consumer
	  reads with ListSerde (ListDeserializer); or, as a member of a Streams
	  consumer group, returning crafted assignment data when elected leader
	  (AssignmentInfo). Because a crafted record remains in its topic, the
	  error can recur on restart. The record size limit (max.message.bytes)
	  does not help, because the allocation is driven by a size field rather
	  than by the input's length.</p>
	<p>Mitigation:</p>
	<p>Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is
	  enabled, restrict write access to each application's internal topics
	  and consumer group to its own principal, and restrict who can produce
	  to topics that are consumed with ListSerde.</p>
	<p>Resolution:</p>
	<p>From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths
	  validate the declared size against the remaining input before
	  allocating and reject input that fails the check.</p>
      </body>
    </description>
    <references>
      <cvename>CVE-2026-111551</cvename>
      <url>https://nvd.nist.gov/vuln/detail/CVE-2026-111551</url>
    </references>
    <dates>
      <discovery>2026-10-28</discovery>
      <entry>2026-10-28</entry>
    </dates>
  </vuln>