---
id: "CVE-2026-114349"
kind: "vulnerability"
aliases: ["CVE-2026-114349"]
title: "Apache Kafka: crafted compressed batch can crash brokers with memory exhaustion"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["brokers", "compacted-topics", "kafka", "package", "self-hosted"]
not_affected_if: ["write-access-restricted-to-trusted-producers"]
published_at: "2026-10-28T17:17:56+00:00"
first_seen_at: "2026-10-28T17:34:09+00:00"
updated_at: "2026-10-28T17:35:07+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114349", "first_seen_at": "2026-10-28T17:34:09+00:00"}]
---

# Apache Kafka: crafted compressed batch can crash brokers with memory exhaustion

Apache Kafka brokers allocate a buffer sized by an attacker-declared decompressed record size before checking it, so a small compressed produce request can force an OutOfMemoryError. An authenticated user with Write on a topic can crash request handlers or the broker JVM, and a record stored on a compacted topic can stop log compaction for the whole broker.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the Kafka broker version against `4.2.2`, `4.3.2`, or `4.4.0`.
- Check whether `max.decompressed.message.bytes` is set at the broker or topic level, for example with `kafka-configs.sh --describe`.
- Check whether brokers run with `-XX:+ExitOnOutOfMemoryError`.

## Fix

- Upgrade Apache Kafka to `4.2.2`, `4.3.2`, or `4.4.0`.
- Set `max.decompressed.message.bytes` at the broker and/or topic level to a bounded value above the largest legitimate decompressed record and well below the broker heap divided by the number of request-handler and cleaner threads.
- Until upgraded and configured, restrict Write access to trusted producers; quotas and `max.message.bytes` do not mitigate this.

## Timeline

- 2026-10-28T17:34:09+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114349

## From the sources

When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.


Impact:

An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from the topic's compression.type and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record  is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal __consumer_offsets and __transaction_state topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.


Mitigation:

Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and max.message.bytes do not mitigate this issue.


Resolution:

From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed body size against max.decompressed.message.bytes before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with InvalidRecordException. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_