External risk intelligence

Apache Kafka Header Denial of Service Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-111115

Apache Kafka is a message broker typically deployed within internal network infrastructure or private clusters to handle data streaming between services. While network-reachable in those environments, it is rarely exposed directly to the public internet, and standard security practices involve placing brokers behind firewalls or VPC controls rather than directly facing external traffic.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a vulnerability in Apache Kafka's handling of flexible protocol versions, specifically within its code-generated readers. The issue allows a client to send a specially crafted request that can exhaust a broker's memory or cause significant processing delays, potentially leading to a denial of service. This occurs before authorization or other security checks are performed, meaning an unauthenticated client could trigger this condition.

  • A flaw allows attackers to crash Kafka brokers.
  • This could disrupt data streaming operations.
  • Confirm relevance and assess exposure to this vulnerability.

Attack Path

How an attacker could exploit the issue

An attacker can exploit this vulnerability by sending a specially crafted request to an Apache Kafka broker. This request, which can be initiated over the network without any prior authentication, tricks the broker into allocating excessive memory for its request headers. This process can overload the broker's resources, leading to a denial of service.

  • Network access required.
  • Malicious request header triggers vulnerability.
  • Broker service disruption.

Live Threat

Current exploitation, exposure, and threat context

A specially crafted request can cause Apache Kafka brokers to allocate excessive memory by declaring an unusually large number of unknown fields in a flexible request header. This can lead to broker instability or denial of service, particularly when using pre-authentication APIs.

  • Broker heap or CPU resources.
  • Malicious request with many declared fields.
  • Broker service denial or instability.

Operational Fix

Recommended remediation, mitigation, and detection steps

For this vulnerability in Apache Kafka, infrastructure and platform teams are likely responsible for initial identification and risk assessment. The first practical step involves confirming the presence of affected Kafka brokers, determining their network reachability, assessing business criticality, and identifying the accountable owner for remediation planning.

  • Identify affected Kafka broker instances.
  • Verify broker network exposure and criticality.
  • Plan remediation based on identified risk.

Supplementary metadata

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.

Frequently asked questions

What is Apache Kafka?

Apache Kafka is a distributed event streaming platform used to build real-time data pipelines and streaming applications. It functions as a message broker, handling high-volume data movement between services. This vulnerability specifically affects how Kafka’s internal code-generated readers process incoming requests using flexible protocol versions.

How does CVE-2026-111115 work?

This is an improper resource allocation vulnerability. When processing flexible request headers, Kafka fails to verify the number of tagged fields declared by a sender against actual buffer limits. A small request can trick the broker into allocating millions of objects, causing heap exhaustion or severe performance stalls.

What triggers this Kafka vulnerability?

It is triggered by sending a specially crafted request to an affected Kafka broker. The request exploits the way flexible request headers are parsed. Note that standard, well-formed requests do not trigger this; the issue specifically requires a malicious request that declares an excessive count of unknown tagged fields.

Do I need to worry about this if my Kafka instance is internal?

Halo Surface Signal indicates that while these brokers are typically placed behind internal network infrastructure or VPC controls, they remain reachable within those environments. You should evaluate if your broker's network configuration allows potentially untrusted clients to reach it, as the vulnerability does not require authentication to trigger.

How do I address this CVE-2026-111115 issue?

The primary resolution is to upgrade your Apache Kafka instances to version 4.2.2, 4.3.2, or 4.4.0, which include proper bounds-checking. As an interim step, you can restrict network access to your broker listeners or lower the socket.request.max.bytes configuration to reduce the potential for memory exhaustion.

References