CVE-2026-114349

Denial of Service
Affects
Apache Kafka
in
Apache Kafka
No items found.
Versions
>=0.11.0.0 <=4.1.2, >=4.2.0 <=4.2.1, >=4.3.0 <=4.3.1

Patch Available.

Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

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 vulnerability (CVE-2026-114349) has been identified in the record decoder Apache Kafka brokers use for compressed record batches, which allows an authenticated principal with Write access on a topic to make the broker allocate a buffer of up to about 2 GiB from a small produce request and fail with an OutOfMemoryError. A crafted record stored on a compacted topic can also stop log compaction for the entire broker until the record is removed.

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

Vulnerability Info

This High-severity vulnerability is found in the org.apache.kafka:kafka_2.11, org.apache.kafka:kafka_2.12 and org.apache.kafka:kafka_2.13 broker packages in multiple versions of Apache Kafka. The broker decodes records with the record classes it shares with the kafka-clients library. When it iterates over a compressed record batch, DefaultRecordBatch decompresses the batch into a stream and reads each record with DefaultRecord.readFrom. That method reads the record's body size as a varint from the decompressed stream and allocates a buffer of that size before checking it against anything:

public static DefaultRecord readFrom(DataInput input,
                                     long baseOffset,
                                     long baseTimestamp,
                                     int baseSequence,
                                     Long logAppendTime) throws IOException {
    int sizeOfBodyInBytes = ByteUtils.readVarint(input);
    ByteBuffer recordBuffer = ByteBuffer.allocate(sizeOfBodyInBytes);
    input.readFully(recordBuffer.array(), 0, sizeOfBodyInBytes);
    ...
}

The size comes from the attacker's data, and the batch CRC does not constrain it, so a compressed produce request of around 90 bytes can declare a body size of up to about 2 GiB. The broker's max.message.bytes limit, the request size limit and client quotas only bound the compressed size on the wire, not this declared size. Legacy (v0 and v1) compressed messages take a similar path: AbstractLegacyRecordBatch iterates the inner messages with a maxMessageSize of Integer.MAX_VALUE, and its DataLogInputStream then calls ByteBuffer.allocate(size) with the declared size.

The broker reaches this decoder when it re-encodes records during produce validation (when a batch's codec differs from the topic's compression.type), and the log cleaner reaches it when it compacts a topic. The allocation raises OutOfMemoryError, which crashes the request handler thread, and on brokers started with -XX:+ExitOnOutOfMemoryError a single request terminates the broker JVM. A crafted record that is stored on disk also crashes any consumer that fetches it. On a compacted topic it terminates the log cleaner thread, which is not restarted. With the default single cleaner thread, compaction stops for every topic on the broker, including __consumer_offsets and __transaction_state, and the condition persists across restarts until the record is removed.

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

  • Peyton Kennedy (finder)
  • Trung Nguyen from CyStack (finder)
  • Bartłomiej Dmitruk from Striga (finder)
  • 임성민 (finder)
  • Mike Read (finder)
  • Salman Aljardan (finder)
  • Yuchao Zhang (finder)
  • Yu Bao from PayPal Cyber Security Team (finder)
  • Vamsi K (finder)
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
High
ID
CVE-2026-114349
PROJECT Affected
Apache Kafka
Versions Affected
>=0.11.0.0 <=4.1.2, >=4.2.0 <=4.2.1, >=4.3.0 <=4.3.1
NES Versions Affected
Published date
November 6, 2026
≈ Fix date
November 4, 2026
Category
Denial of Service
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Apache Kafka
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.