CVE-2026-111115

Overview

Apache Kafka is an open-source distributed event streaming platform used for high-throughput, fault-tolerant data pipelines and stream processing. It stores records in partitioned, replicated, append-only logs on a cluster of brokers, and exposes producer, consumer, admin, Streams, and Connect APIs for publishing, subscribing to, and processing those records. The Java client and server components are published as Maven artifacts under org.apache.kafka.

A Denial of Service (DoS) vulnerability (CVE-2026-111115) has been identified in the code-generated protocol readers of Apache Kafka, which allows attackers to exhaust broker heap memory by sending a request whose flexible header declares a very large number of tagged fields. Because the header of pre-authentication requests such as ApiVersions v3 is parsed this way, the allocations can happen before authentication, and no ACL or quota is needed to trigger them.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Apache Kafka.

‍

Details

Module Info

• Product: Apache Kafka
• Affected packages: org.apache.kafka:kafka-clients
• Affected versions: >=2.4.0 <=4.1.2, >=4.2.0 <=4.2.1, >=4.3.0 <=4.3.1
• GitHub repository: https://github.com/apache/kafka
• Published packages: https://central.sonatype.com/artifact/org.apache.kafka/kafka-clients
• Package manager: Maven
• Fixed in:
  • OSS Apache Kafka 4.2.2, 4.3.2, 4.4.0
  • NES for Apache Kafka v3.1.5

Vulnerability Info

This High-severity vulnerability is found in the org.apache.kafka:kafka-clients package in multiple versions of Apache Kafka. Kafka's message classes are produced by a code generator, and for flexible protocol versions every generated read method ends by reading a tagged-field count from the wire and looping over it. The count comes straight from the sender and is only bounded by the overall request frame size (socket.request.max.bytes); it is never checked against the bytes remaining in the buffer or against any fixed maximum:

buffer.printf("int _numTaggedFields = _readable.readUnsignedVarint();%n");
buffer.printf("for (int _i = 0; _i < _numTaggedFields; _i++) {%n");
buffer.incrementIndent();
buffer.printf("int _tag = _readable.readUnsignedVarint();%n");
buffer.printf("int _size = _readable.readUnsignedVarint();%n");

Any tag the message does not define falls through to readUnknownTaggedField, which keeps a new RawTaggedField object in a list for each entry:

default List<RawTaggedField> readUnknownTaggedField(List<RawTaggedField> unknowns, int tag, int size) {
    if (unknowns == null) {
        unknowns = new ArrayList<>();
    }
    byte[] data = readArray(size);
    unknowns.add(new RawTaggedField(tag, data));
    return unknowns;
}

An unknown tagged field can be encoded in as little as two bytes (tag 0, size 0), so a request of a few tens of megabytes can declare around 20 million tagged fields and force roughly that many object allocations. Flexible request headers (header version 2, used by APIs such as ApiVersions v3) are read by this same generated code on the broker's network thread, before authorization, request dispatch or quota accounting, and for pre-authentication APIs such as ApiVersions before authentication. An unauthenticated client that can reach a broker listener can therefore exhaust the broker's heap or cause process-wide garbage collection stalls, denying service to all clients. Lowering socket.request.max.bytes and restricting network access to broker listeners reduces this exposure but does not remove it.

‍

Mitigation

Only recent versions of Apache Kafka are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. The Apache Kafka project does bugfix releases only for the last three minor releases; see the project's time-based release plan.

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache Kafka to a currently supported release that contains the fix, such as 4.2.2.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Mufeed VH (finder)
• Vivek R (finder)