CVE-2026-111551
| Severity | 7.5 High CVSS 3.1 |
|---|---|
| Weakness | Improper input validation (CWE-20) |
| Published | 28 Oct 2026 |
| Updated | 5 Nov 2026 |
Published 17 days ago. NVD often adds the list of affected products days or weeks after a CVE is published, and the other sources we check lag too. The scope and status here may change.
Description
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.
CWE-400 · Uncontrolled resource consumptionCWE-789
Exploitation status
No public exploit
No exploit has been reported in the sources we check.
Exploitation status
- CISA KEV not listed
- VulnCheck KEV not listed
- CISA Vulnrichment exploitation: none
- Indexed PoC none indexed
- EPSS 0.50% chance in 30 days
Waratek protection
Waratek has a rule that blocks attacks on this vulnerability.
- Protection full Deserialization
- Action available security rule
- Review automated Inferred
- Record active
| Decided by | A vulnerability class already blocked by an ARMR security rule |
|---|---|
| Finding | Protected by Waratek's ARMR deserialization security rule, which blocks this class of attack at the JVM level without a rule written for this CVE specifically. The CVE's description identifies a deserialization vulnerability. Matched by description (CWE-20, CWE-400, CWE-789 were assigned, but none settles the class on its own). |
How to mitigate CVE-2026-111551
Apply the vendor's fix. Until you can, Waratek RASP blocks exploitation with its deserialization rule. It runs inside the Java application, with no code changes.
References
| URL | Tags |
|---|---|
| https://kafka.apache.org/cve-list | |
| http://www.openwall.com/lists/oss-security/2026/10/28/13 |
Timeline
Timeline
| Published | 2026-10-28 | By the CVE Program. |
|---|---|---|
| NVD record modified | 2026-11-05 | NVD's own last-modified date for this record. |