Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches

MITRE NVD CVE.ORG JSON API

Summary

CVECVE-2026-114349
StatePUBLISHED
Assignerapache
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-10-28 17:17:56 UTC
Updated2026-10-28 20:17:19 UTC
DescriptionWhen 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.

Risk And Classification

Problem Types: CWE-400 | CWE-789 | CWE-1284 | CWE-789 CWE-789 Memory allocation with excessive size value | CWE-400 CWE-400 Uncontrolled Resource Consumption | CWE-1284 CWE-1284 Improper validation of specified quantity in input

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Apache Software Foundation Apache Kafka affected 0.11.0.0 4.1.2 semver Not specified
CNA Apache Software Foundation Apache Kafka affected 4.2.0 4.2.1 semver Not specified
CNA Apache Software Foundation Apache Kafka affected 4.3.0 4.3.1 semver Not specified

References

ReferenceSourceLinkTags
www.openwall.com/lists/oss-security/2026/10/28/18 af854a3a-2127-422b-91ae-364da2661108 www.openwall.com
kafka.apache.org/cve-list [email protected] kafka.apache.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

Vendor Comments And Credit

Discovery Credit

CNA: Peyton Kennedy <[email protected]> (en)

CNA: Trung Nguyen <[email protected]>, CyStack (en)

CNA: Bartłomiej Dmitruk <[email protected]>, Striga (en)

CNA: 임성민 <[email protected]> (en)

CNA: Mike Read (GitHub: Michael-JRead) (en)

CNA: Salman Aljardan <[email protected]> (en)

CNA: Yuchao Zhang <[email protected]> (en)

CNA: Yu Bao <[email protected]>, PayPal Cyber Security Team (en)

CNA: Vamsi K <[email protected]> (en)

CNA: Srinivas Akhil Mallela <[email protected]> (en)

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report