CVE-2026-111551
Low risk· EPSS 13%Exploitation Probability (EPSS)
Low risk13th percentile - higher than 13% of all known CVEs
Summary
Several Apache Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer without checking the bytes actually available. A small crafted input can declare a very large size and force a multi-gigabyte allocation, causing an OutOfMemoryError. Affected paths include ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, and AssignmentInfo in Kafka Streams, and ListDeserializer in the clients library.
Risk Assessment
An attacker can trigger an oversized allocation that crashes the affected consumer or Kafka Streams thread, and because the crafted record remains in its topic, the error can recur on restart. The broker and the rest of the cluster are unaffected, but availability of consuming applications may be disrupted.
Recommendation
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, which validate the declared size against the remaining input before allocating. Additionally, where authorization is enabled, restrict write access to each application's internal topics and consumer group and restrict who can produce to topics consumed with ListSerde.
Other vulnerabilities in Apache Kafka
See all- CVE-2026-33557Critical
In Apache Kafka, the default JWT validator class (`DefaultJwtValidator`) accepts any JWT token without validating its signature, issuer, or audience. An attacker can generate a token from any issuer with any username, and the broker will accept it.
- CVE-2026-83525Low risk· EPSS 8%
Incorrect operator (CWE-480) in the FetchSnapshot RPC handler in Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2, allows an authenticated attacker with CLUSTER_ACTION privilege to cause a denial of service. Exploitation occurs via a crafted FetchSnapshotRequest with an empty topics array or a topic with no partitions, terminating the controller process.
- CVE-2026-114349Low risk· EPSS 16%
A vulnerability in Apache Kafka allows an authenticated producer with Write permission on a topic to declare a decompressed body size of up to about 2 GiB in a compressed record, forcing a buffer allocation and causing an OutOfMemoryError. This can crash broker request-handler threads, consumers, and permanently stop the log-cleaner thread on compacted topics.
- CVE-2026-112375Low risk· EPSS 13%
An authenticated Kafka principal with no authorization grants can make a broker read a file or environment variable from the broker host and return its contents. An IncrementalAlterConfigs or AlterConfigs request targeting a BROKER resource reaches configuration validation before any authorization check, and configuration-variable resolution (${file:...}, ${env:...}) bypasses the config-providers allowlist added as mitigation for CVE-2024-31141.
- CVE-2026-111115Low risk· EPSS 15%
A vulnerability in Apache Kafka's code-generated readers for flexible protocol versions reads a tagged-field count declared by the sender and retains a RawTaggedField object for each unknown field. The count was bounded only by the outer request frame size, not by remaining buffer bytes or a fixed cap, allowing a modest request to declare tens of millions of tagged fields and force one object allocation per field. Flexible request headers are parsed before authorization, so the amplification applies pre-authentication.
- CVE-2026-111108Low risk· EPSS 19%
Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender, checked only against the bytes remaining in the request buffer (assuming about one byte per element). For a keyed array the reader allocates an ImplicitLinkedHashCollection of capacity (2 * count + 1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern affects all Kafka API types with an array field.
- CVE-2026-111073Low risk· EPSS 10%
The vulnerability affects the broker-side PushTelemetry API (KIP-714) in Apache Kafka, which validates only the compressed size of a client's metrics payload against telemetry.max.bytes before decompressing it without any limit on the decompressed output size. A small, highly compressible payload can expand to hundreds of megabytes of broker heap, causing an OutOfMemoryError.
- CVE-2026-110985Low risk· EPSS 2%
In an Apache Kafka broker using SASL/OAUTHBEARER with the default validator (DefaultJwtValidator), when sasl.oauthbearer.jwks.endpoint.url is unset and no custom verification key resolver is supplied, the validator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer. The broker starts without any warning and accepts any structurally valid JWT, including "alg":"none" tokens. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set.
- CVE-2026-110952Low risk· EPSS 2%
An Apache Kafka broker authenticating clients via SASL/OAUTHBEARER with the bundled JWKS-backed validator always verifies the JWT signature, but does not enforce the issuer (iss) or audience (aud) claims unless sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are explicitly configured. As a result, a validly signed token from a different issuer or lacking an aud claim may be accepted. Exposure mainly affects deployments whose JWKS endpoint serves signing keys for multiple issuers or shared signing keys.
- CVE-2026-41115Medium
An improper authorization vulnerability has been identified in Apache Kafka. The CONSUMER_GROUP_DESCRIBE (69) API validates the DESCRIBE operation on the GROUP resource instead of the READ operation as documented. This can result in misconfigured ACLs and unintended security postures.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS