CVE-2026-111551 in Kafka
Summary
by MITRE • 10/28/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability described involves a critical flaw in several Apache Kafka deserialization pathways where untrusted data is used to determine memory allocation sizes without adequate validation against available buffer limits. Specifically, components such as ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo within the Kafka Streams library, and ListDeserializer in the clients library fail to verify that the size or count fields declared in serialized input do not exceed the actual bytes present in the data stream. This lack of boundary checking allows an attacker to craft a malicious payload containing artificially inflated size values, which forces the application to attempt allocating multi-gigabyte arrays, collections, or byte buffers. The root cause is classified under CWE-1325: Incorrect Buffer Size Calculation and CWE-789: Uncontrolled Memory Allocation, as the system trusts external input for resource sizing without verifying its consistency with physical constraints.
The operational impact of this vulnerability is a denial of service resulting in application crashes due to OutOfMemoryError conditions. When a consumer or Kafka Streams thread processes such crafted records, it attempts to allocate memory far beyond what is available on the host machine, leading to immediate termination of the affected process. Crucially, while individual consumers and streams applications are compromised, the broker infrastructure and the broader cluster remain unaffected because these deserialization paths reside within client-side processing logic rather than server-side message handling. The attack surface varies depending on the specific component exploited; for instance, an attacker can target internal changelog or repartition topics in Streams applications by writing crafted records that trigger errors during stream processing. Alternatively, attackers may exploit ListSerde by producing malicious messages to any topic consumed via this deserializer, or manipulate group-assignment data if they hold leadership roles within a consumer group using AssignmentInfo decoding.
A significant characteristic of this vulnerability is its persistence and recurrence potential due to the nature of Kafka's log-based storage model. Because crafted records containing oversized size fields are persisted in their respective topics, any subsequent restart of the affected application or reprocessing of historical data will trigger the same memory exhaustion error repeatedly. Standard mitigation strategies such as configuring max.message.bytes on brokers do not prevent this attack vector because the vulnerability is driven by logical field values rather than physical message length limits. The broker enforces size constraints based on total byte count, but it does inspect individual deserialization parameters for internal consistency before passing data to client libraries. Consequently, even small payloads with large declared sizes can bypass transport-level checks and reach the vulnerable deserialization code paths.
To mitigate this risk, organizations should upgrade immediately to Apache Kafka versions 4.2.2, 4.3.2, or 4.4.0, which implement strict validation logic that compares declared size fields against remaining input bytes before allocating memory. Inputs failing these checks are rejected rather than processed further. In environments where upgrading is not immediately feasible, administrative controls can reduce exposure by restricting write access to internal topics and consumer groups using authorization mechanisms like ACLs or RBAC. Specifically, limiting production rights for topics consumed with ListSerde prevents external actors from injecting malicious payloads into those data streams. Additionally, ensuring that only authorized principals manage group assignments limits the risk associated with AssignmentInfo exploitation. These measures align with ATT&CK technique T1496: Resource Hijacking, as they aim to prevent adversaries from consuming excessive system resources through crafted inputs designed to destabilize target systems.