Zero Radar
← feed
HighVulnerabilityCVE-2026-111115updated 28 Oct 2026, 17:46 UTC

Apache Kafka brokers can run out of memory from a crafted request

A single oversized-looking request can make a Kafka broker use up its memory and stop responding. This can happen before any login check, so the broker can be knocked offline by anyone who can reach it.

Fixed in Apache Kafka 4.2.2, 4.3.2, or 4.4.0Official, 2 sources
SeverityHighVulnerability
Being exploited?UnclearNo reports either way yet
Fix available?YesApache Kafka 4.2.2, 4.3.2, or 4.4.0 · since 28 Oct 2026
How sure is this?Official, 2 sourcesBacked by an official source

How the attack works simplified

  1. 1Attacker sends requestTens of megabytes, sent before any login
  2. 2Broker reads headerParsed on the network thread
  3. 3Field count declaredAbout 20 million tagged fields claimed
  4. 4Objects allocatedOne object per declared field, no cap
  5. 5Heap exhaustedGarbage collection stalls the process
  6. ResultBroker stops serving clients

What happened

Kafka's code-generated readers for flexible protocol versions trust a tagged-field count from the sender and allocate one object per declared field, bounded only by socket.request.max.bytes. Each field can be as small as two bytes, so a request of tens of megabytes can force about 20 million allocations.

Why it is dangerous: Heap exhaustion or long garbage-collection pauses take the broker offline, disrupting every producer and consumer that depends on it. The header is parsed before authorization and quotas, so no Kafka credentials are needed to trigger it.

Are you affected?

You are affected if you run Apache Kafka 2.4.0 through 4.1.2, 4.2.0 through 4.2.1, or 4.3.0 through 4.3.1 with broker listeners reachable from clients or untrusted networks.

Apache Kafka 2.4.0 to 4.1.2; 4.2.0 to 4.2.1; 4.3.0 to 4.3.1

What to do

  1. Upgrade Apache Kafka brokers to 4.2.2, 4.3.2, or 4.4.0
  2. Until upgraded, lower socket.request.max.bytes to reduce the attack surface
  3. Restrict network access to broker listeners to trusted clients only

Timeline

  1. 28 Oct 2026, 17:17 UTC
    Publicly disclosed
  2. 28 Oct 2026, 17:33 UTC
    Reported by oss-security · oss-security
  3. 28 Oct 2026, 17:46 UTC
    Picked up by Zero Radar
  4. 28 Oct 2026, 17:46 UTC
    NVD reported on it · NVD

Sources 2 reports, oldest first

Official vendor, government CERT or advisory database

Security researchers research teams and mailing lists

Technical details

ID
CVE-2026-111115
Disclosed
28 Oct 2026, 17:17 UTC
On Zero Radar
28 Oct 2026, 17:46 UTC (28 min after disclosure)
Last change
28 Oct 2026, 17:46 UTC

The plain-language parts and the attack diagram were written by an AI model (anthropic/claude-haiku-5.5) from the sources above. Facts like versions, exploitation and dates come from the sources themselves. How Zero Radar works

Apache Kafka brokers can run out of memory from a crafted request · Zero Radar