CVE-2026-111108
Low risk· EPSS 19%Exploitation Probability (EPSS)
Low risk19th percentile - higher than 19% of all known CVEs
Summary
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.
Risk Assessment
An unauthenticated attacker can send a few concurrent requests declaring a very large array length and exhaust the broker heap, crashing it with an OutOfMemoryError. On listeners requiring authentication, valid credentials without specific ACLs suffice because parsing precedes authorization.
Recommendation
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lower socket.request.max.bytes and restrict network access to broker listeners, which reduces but does not remove exposure.
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-111551Low risk· EPSS 13%
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.
- 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-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)
Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then 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 is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large= array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).
Vulnerability data from NVD (NIST) · CISA KEV · EPSS