External risk intelligence

Apache Kafka Heap Allocation Denial-of-Service Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-111108

Apache Kafka is a distributed data streaming platform typically deployed within internal network segments or private clouds to handle backend data pipelines. While it may be reachable over a network, it is rarely exposed directly to the public internet in common deployment patterns, and access is generally restricted to internal services, applications, and administrators.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in Apache Kafka's handling of array data in requests can allow an unauthenticated attacker to cause a denial-of-service by crashing the system with a specially crafted request. This issue impacts the availability of the data streaming platform by consuming excessive memory before any security checks are performed.

Malicious requests can crash Kafka servers.
System availability is at risk before authorization.
Assess Kafka's direct network exposure.

Attack Path

How an attacker could exploit the issue

An attacker can target Apache Kafka brokers by sending specially crafted requests that declare an extremely large number of elements in an array. Even if the total size of the request is manageable, the broker's protocol readers will attempt to pre-size a collection based on this declared count. This can lead to a massive heap allocation that far exceeds the actual data, consuming all available memory and causing the broker to crash. This attack can occur before any authentication or authorization checks are performed, and it affects all API types that include an array field.

Unauthenticated or authenticated network access.
Sending requests with excessively large array declarations.
Broker crash due to excessive memory allocation.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could impact the availability of Apache Kafka brokers by allowing specially crafted requests to consume excessive memory. When processing requests containing array fields, a flaw in how array sizes are checked can lead to massive heap allocations, potentially crashing the broker and disrupting data streaming services. This could occur on listeners that do not require authentication, enabling unauthenticated attackers to cause denial-of-service conditions.

Broker heap memory.
Large array declarations in requests.
Broker crashes and service disruption.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-world remediation likely falls to the platform or infrastructure teams managing Apache Kafka, as request parsing precedes authorization checks and affects broker heap allocations. The initial practical move is to identify all Kafka broker instances, assess their network exposure and business criticality, and then determine the accountable owner for each. Planning remediation should prioritize instances with the greatest exposure and impact.

Platform/Infrastructure teams own remediation.
Verify broker network exposure and criticality.
Plan staged remediation based on risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Apache Kafka?

Apache Kafka is a high-performance distributed streaming platform designed to handle massive volumes of real-time data. It acts as a central nervous system for data pipelines, allowing various services and applications to publish, subscribe to, and process streams of records. Because it manages complex data flows between distributed systems, it relies on internal protocol readers to efficiently parse incoming requests, a mechanism now found to contain this specific vulnerability.

How does CVE-2026-111108 cause a system crash?

This vulnerability involves an issue known as uncontrolled resource consumption, specifically categorized as CWE-770 and CWE-789. When Kafka receives a request with an array, it pre-allocates memory based on the element count declared by the sender. An attacker can declare an extremely high count, forcing the broker to reserve a massive amount of heap memory immediately. Because this happens before any security validation, it can lead to an OutOfMemoryError, crashing the broker.

Do I need to send a large file to trigger this vulnerability?

No. The vulnerability does not depend on the actual size of the request on the network. The trigger is simply the declared array length in the request metadata. Because the system pre-allocates memory based on this declared number rather than the actual bytes provided, an attacker can crash the broker by sending a relatively small network request that claims to contain a massive number of elements, bypassing the need for large data transfers.

Why should I care about this if my Kafka instance is internal?

According to Halo Surface Signal, Apache Kafka is typically deployed within private network segments. However, even if your instance is not directly on the public internet, it may still be reachable by compromised internal services or malicious actors inside your perimeter. Because the vulnerability exists at the protocol parsing level, any entity with network access to the broker can potentially exploit it, making internal risk assessment critical.

Is there a way to protect my Kafka brokers immediately?

The most effective resolution is upgrading your software to version 4.2.2, 4.3.2, or 4.4.0, which introduces strict caps on array pre-allocation. As an immediate interim step, you can reduce your risk by lowering the 'socket.request.max.bytes' configuration setting to limit the impact of incoming requests. Additionally, strictly restricting network access to your broker listeners can reduce the number of potential sources capable of sending the malicious requests.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.