Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain produce/offset-commit or consumer-group access
-
ExploitCraft record declaring oversized size/count field
-
ExecutionVulnerable deserializer allocates multi-gigabyte buffer
-
ImpactOutOfMemoryError crashes consumer or Streams thread (recurs on restart)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Exploitation requires the ability to place crafted data on a path the victim deserializes, and the exact prerequisite differs per path. Kafka Streams internal paths (ProcessorRecordContext header count, ChangedDeserializer varint value length, CombinedKeySchema foreign-key length - which can also yield a negative size, ProcessorMetadata key length) require the attacker to write a crafted record to that application's internal changelog or repartition topics, or to commit crafted offset metadata to its consumer group. The AssignmentInfo path requires the attacker to be a member of the Streams consumer group and be elected group leader so it can return crafted group-assignment data. The ListDeserializer path requires that a consumer actually reads a topic using ListSerde and that the attacker can produce a crafted record to that topic. Limiting factors: where Kafka authorization (ACLs) is enabled, write access to internal topics, offset-metadata commits, and ListSerde-consumed topics is restricted to authorized principals, which blocks most paths; the ListSerde path is only reachable if ListSerde is in use; and impact is confined to denial of service of the consumer/Streams thread (no broker or cluster impact, no code execution, no data disclosure). The record size limit max.message.bytes does not limit exploitation because the allocation is driven by a declared size field, not by the record's actual byte length, and the crafted record persists so the crash recurs on restart. |
| Impact | No CVSS vector or score is provided in the input (CVSS: N/A), and no EPSS score is available, so quantitative exploitation-probability and severity signals cannot be compared - this is a notable data gap that should be flagged to the team. The remaining signals point to a moderate, availability-only issue: CWE-789 (memory allocation with excessive size value), impact strictly a denial of service via OutOfMemoryError on the affected consumer or Kafka Streams thread, with the broker and the rest of the cluster explicitly unaffected and no confidentiality or integrity impact. KEV status is not present (no active exploitation confirmed) and no public exploit or PoC reference is supplied. The vuln.today decision label is 'this_week', consistent with a prioritize-but-not-emergency DoS rather than a critical RCE. The practical risk is tempered by the fact that most reachable paths require the attacker to produce to a Streams application's internal changelog/repartition topics, commit crafted offset metadata to its consumer group, be a member of its consumer group (AssignmentInfo leader path), or produce to a topic consumed with ListSerde - access that is restricted in clusters with authorization enabled. The risk is elevated by persistence: a crafted record stays in the topic, so the crash recurs on restart, and max.message.bytes does not mitigate it because the allocation is driven by a declared size field, not by actual input length. Net: a real, worth-patching availability bug with a built-in re-crash loop, but not a high-urgency widespread-exploitation scenario on the evidence available. |
| Exploit ScenarioDerived | An attacker able to produce to a vulnerable topic writes a single crafted record whose internal size/count field declares a very large value (for example into a topic consumed with ListSerde, or into a Kafka Streams internal changelog/repartition topic). When the consumer or Streams thread deserializes it, it allocates a multi-gigabyte buffer and dies with an OutOfMemoryError, and because the record persists the thread crashes again on every restart. No public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
RemediationAI
Vendor-released patch: Apache Kafka 4.2.2, 4.3.2, and 4.4.0. In those releases the affected deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check; upgrading is the complete fix. Until upgrade, the mitigations described by the vendor are authorization-based: where Kafka authorization is enabled, restrict write access to each Streams application’s internal changelog and repartition topics and to its consumer group to that application’s own principal, and restrict which principals can produce to topics that are consumed with ListSerde. These ACL restrictions block the Streams internal-topic, offset-metadata, group-assignment, and ListSerde paths for unauthorized principals, but they are only effective when authorization is enabled and do not change the fact that max.message.bytes does not prevent the oversized allocation; a crafted record can persist in a topic and cause the OutOfMemoryError to recur after restart. Advisory: https://kafka.apache.org/cve-list.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CWE-789 (Memory Allocation with Excessive Size Value) describes the root cause: several Kafka deserialization routines read a length, count, or varint size from attacker-influenced bytes and pass it directly to an array, collection, or ByteBuffer allocation without first checking it against the number of bytes remaining in the input. The affected code lives in Kafka Streams-ProcessorRecordContext uses a header count, ChangedDeserializer uses a varint value length, CombinedKeySchema uses a foreign-key length that can also become negative, ProcessorMetadata uses a key length, and AssignmentInfo decodes group-assignment data-and in the clients library’s ListDeserializer used by ListSerde. Because the allocation is driven by the declared size field rather than by the record’s actual length, the broker’s max.message.bytes limit does not constrain the attack. The assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector reflects network reachability and unauthenticated protocol access, but practical exploitation depends on the attacker’s ability to write crafted records to a Streams internal topic, commit crafted offset metadata, return crafted assignment data as Streams group leader, or produce to a ListSerde-consumed topic; Kafka ACLs restrict those paths when authorization is enabled. The common outcome is an OutOfMemoryError that terminates the consumer or Streams thread, with no broker or cluster-wide impact and no code execution or data disclosure.
Know when Apache Kafka gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Network-reachable via produced records with no complexity; PR:N reflects default clusters without authorization (ACLs raise this to PR:L); availability-only DoS, so C:N/I:N/A:H and scope unchanged as the broker is unaffected.
Primary rating from Vendor (apache).
DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-111551 presents a high-severity risk to applications using Apache Kafka's client library and Kafka Streams, where unauthenticated attackers who can introduce crafted data could cause memory exhaustion and application crashes. Customer-facing services relying on these components may experience outages, impacting availability and revenue. Leadership should prioritize remediation, though the absence of known active exploitation and available patches means we must rely on interim controls.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce Kafka ACLs to block unauthorized writes to changelog, repartition, and offset topics; restrict group-assignment privileges to trusted Streams leaders; limit JVM heap and enable heap dumps; monitor for OutOfMemoryErrors and unusual large allocations; avoid using ListSerde with untrusted producers.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
More in Apache Kafka
View allApache Kafka 4.1.0 and 4.1.1 accept forged JWT tokens without signature validation, allowing remote unauthenticated atta
Apache Kafka's NetworkClient component logs entire request and response payloads at DEBUG level, exposing sensitive auth
Improper authorization in Apache Kafka 4.0.0-4.3.0 arises from a discrepancy between the documented ACL requirement and
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit
Apache Kafka brokers that have an authorizer enabled will read a file or environment variable from the broker host and r
Kafka Connect workers leak plaintext secrets through the REST API's /connector-plugins/{connector-type}/config/validate
Authentication bypass in Apache Kafka Connect's isolated admin REST API allows unauthenticated network attackers to read
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an in
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array eleme
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714)
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endp
EUVD-2026-112172
GHSA-fpf4-qx46-w5rg
CVE.org
Exploit-DB