Multiple Kafka deserialization mechanisms read a size or count field from inbound data and allocate a data structure of that exact size without verifying that enough bytes remain. An attacker can send a record that declares a very large, possibly negative, size, causing the JVM to attempt a multi‑gigabyte allocation. The resulting OutOfMemoryError crashes the consumer or Streams processing thread, but the broker and other cluster nodes continue normally. The attacker’s payload can persist on the topic, leading to repeated crashes whenever the topic is read again.

Apache Kafka platforms are affected; the exact set of vulnerable versions is not listed, but the fix is included in Kafka 4.2.2, 4.3.2, and 4.4.0. Vulnerable deserializers include ProcessorRecordContext in Kafka Streams, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo, and ListDeserializer in the client library.

The EPSS score is not published and the vulnerability is not included in the CISA KEV catalog, suggesting no publicly documented exploits. Nonetheless the risk is high if the attacker can produce faulty records to an internal changelog, repartition topic, or any topic used with ListSerde, as the error manifests on any read. Attackers require access to produce to the victim’s Kafka topics or to be a member of a Streams consumer group to inject assignment data. Even with limited write rights, crafted metadata can trigger an OOM in a coordinator if proper permissions are not enforced. In environments where authorization is turned off, the attack surface is broad; with authorization enabled, the surface can be reduced but remains significant if principals are able to write to internal partitions or produce to ListSerde–consumed topics.