CVE-2026-111551None▾ SunlitSeveral 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 …
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 29.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
0.2%
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.
org.apache.kafka:kafka-streams >= 0.10.0.0 <= 4.1.2org.apache.kafka:kafka-streams >= 4.2.0 <= 4.2.1org.apache.kafka:kafka-streams >= 4.3.0 <= 4.3.1org.apache.kafka:kafka-clients >= 0.10.0.0 <= 4.1.2org.apache.kafka:kafka-clients >= 4.2.0 <= 4.2.1org.apache.kafka:kafka-clients >= 4.3.0 <= 4.3.1Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-111108NoneApache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers
CVE-2026-114349NoneApache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches
CVE-2026-111073NoneApache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service
CVE-2026-111496NoneApache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation
CVE-2026-110985NoneApache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured
CVE-2026-110952NoneApache Kafka: Broker does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default