{"api_version":"1","generated_at":"2026-10-28T20:53:31+00:00","cve":"CVE-2026-114349","urls":{"html":"https://cve.report/CVE-2026-114349","api":"https://cve.report/api/cve/CVE-2026-114349.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-114349","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-114349"},"summary":{"title":"Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches","description":"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.\n\n\nImpact:\n\nAn 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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.","state":"PUBLISHED","assigner":"apache","published_at":"2026-10-28 17:17:56","updated_at":"2026-10-28 20:17:19"},"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"],"metrics":[],"references":[{"url":"http://www.openwall.com/lists/oss-security/2026/10/28/18","name":"http://www.openwall.com/lists/oss-security/2026/10/28/18","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://kafka.apache.org/cve-list","name":"https://kafka.apache.org/cve-list","refsource":"security@apache.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-114349","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-114349","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 0.11.0.0 4.1.2 semver","platforms":[]},{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 4.2.0 4.2.1 semver","platforms":[]},{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 4.3.0 4.3.1 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Peyton Kennedy <pkennedy@endor.ai>","lang":"en"},{"source":"CNA","value":"Trung Nguyen <trungnh@cystack.net>, CyStack","lang":"en"},{"source":"CNA","value":"Bartłomiej Dmitruk <bartek@striga.ai>, Striga","lang":"en"},{"source":"CNA","value":"임성민 <at_haemil@naver.com>","lang":"en"},{"source":"CNA","value":"Mike Read (GitHub: Michael-JRead)","lang":"en"},{"source":"CNA","value":"Salman Aljardan <salman1aljardan@gmail.com>","lang":"en"},{"source":"CNA","value":"Yuchao Zhang <ndaugoing@gmail.com>","lang":"en"},{"source":"CNA","value":"Yu Bao <yubao@paypal.com>, PayPal Cyber Security Team","lang":"en"},{"source":"CNA","value":"Vamsi K <xh081ix@gmail.com>","lang":"en"},{"source":"CNA","value":"Srinivas Akhil Mallela <srinivasakhil@gmail.com>","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"providerMetadata":{"dateUpdated":"2026-10-28T20:06:58.727Z","orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE"},"references":[{"url":"http://www.openwall.com/lists/oss-security/2026/10/28/18"}],"title":"CVE Program Container"}],"cna":{"affected":[{"collectionURL":"https://repo.maven.apache.org/maven2","defaultStatus":"unaffected","packageName":"org.apache.kafka:kafka","packageURL":"pkg:maven/org.apache.kafka/kafka","product":"Apache Kafka","vendor":"Apache Software Foundation","versions":[{"lessThanOrEqual":"4.1.2","status":"affected","version":"0.11.0.0","versionType":"semver"},{"lessThanOrEqual":"4.2.1","status":"affected","version":"4.2.0","versionType":"semver"},{"lessThanOrEqual":"4.3.1","status":"affected","version":"4.3.0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"reporter","value":"Peyton Kennedy <pkennedy@endor.ai>"},{"lang":"en","type":"reporter","value":"Trung Nguyen <trungnh@cystack.net>, CyStack"},{"lang":"en","type":"reporter","value":"Bartłomiej Dmitruk <bartek@striga.ai>, Striga"},{"lang":"en","type":"reporter","value":"임성민 <at_haemil@naver.com>"},{"lang":"en","type":"reporter","value":"Mike Read (GitHub: Michael-JRead)"},{"lang":"en","type":"reporter","value":"Salman Aljardan <salman1aljardan@gmail.com>"},{"lang":"en","type":"reporter","value":"Yuchao Zhang <ndaugoing@gmail.com>"},{"lang":"en","type":"reporter","value":"Yu Bao <yubao@paypal.com>, PayPal Cyber Security Team"},{"lang":"en","type":"reporter","value":"Vamsi K <xh081ix@gmail.com>"},{"lang":"en","type":"remediation developer","value":"Srinivas Akhil Mallela <srinivasakhil@gmail.com>"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<br><div>When a broker decodes a compressed record batch, the per-record decoder reads a declared body&nbsp;<span>size from the decompressed stream and allocates a buffer of that size before validating it&nbsp;</span><span>against the bytes available or any configured limit. The size is attacker-controlled, and the&nbsp;</span><span>batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce&nbsp;</span><span>request can declare a body size of up to about 2 GiB and force the broker to attempt that&nbsp;</span><span>allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request&nbsp;</span><span>size limit, and client/broker quotas bound only the compressed wire size, not the declared&nbsp;</span><span>decompressed size.</span></div><br><div>Impact:</div><div>An authenticated principal with Write on a topic can crash broker request-handler threads&nbsp;<span>(reached when a batch's codec differs from the topic's compression.type and records are&nbsp;</span><span>re-encoded) and any consumer that fetches the record, denying service. On brokers started&nbsp;</span><span>with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the&nbsp;</span><span>broker JVM. More seriously, a&nbsp;crafted record&nbsp;&nbsp;</span><span>is accepted at ingest and written to disk; when the log-cleaner later reads it&nbsp;</span><span>on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner&nbsp;</span><span>thread, which is not restarted. With the default of a single cleaner thread, log compaction&nbsp;</span><span>then stops for the entire broker, including the internal __consumer_offsets and&nbsp;</span><span>__transaction_state topics, and the condition persists across restarts until the offending&nbsp;</span><span>record is removed. The impact is availability only; no data is disclosed or altered.</span></div><br><div>Mitigation:</div><div>Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the&nbsp;<span>broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is&nbsp;</span><span>not sufficient: for backward compatibility this configuration defaults to an effectively&nbsp;</span><span>unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a&nbsp;</span><span>value at or slightly above the largest legitimate decompressed record your applications&nbsp;</span><span>produce, and comfortably below the broker heap divided by the number of request-handler and&nbsp;</span><span>cleaner threads. Until you can upgrade and configure the limit, restrict Write access to&nbsp;</span><span>trusted producers; quotas and max.message.bytes do not mitigate this issue.</span></div><br><div>Resolution:</div><div>From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed&nbsp;<span>body size against max.decompressed.message.bytes before allocating, on the produce-validation,&nbsp;</span><span>log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with&nbsp;</span><span>InvalidRecordException. Operators must set this configuration to a bounded value to be protected,&nbsp;</span><span>as its default is effectively unlimited.</span></div>"}],"value":"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.\n\n\nImpact:\n\nAn 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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."}],"metrics":[{"other":{"content":{"text":"important"},"type":"Textual description of severity"},"scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-789","description":"CWE-789 Memory allocation with excessive size value","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-400","description":"CWE-400 Uncontrolled Resource Consumption","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-1284","description":"CWE-1284 Improper validation of specified quantity in input","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-28T16:46:54.920Z","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","shortName":"apache"},"references":[{"tags":["vendor-advisory"],"url":"https://kafka.apache.org/cve-list"}],"source":{"discovery":"EXTERNAL"},"title":"Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches","x_generator":{"engine":"Vulnogram 1.0.3"}}},"cveMetadata":{"assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","assignerShortName":"apache","cveId":"CVE-2026-114349","datePublished":"2026-10-28T16:46:54.920Z","dateReserved":"2026-10-21T08:14:55.090Z","dateUpdated":"2026-10-28T20:06:58.727Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-28 17:17:56","lastModifiedDate":"2026-10-28 20:17:19","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"],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"114349","Ordinal":"1","Title":"Apache Kafka: Denial of service via unbounded memory allocation ","CVE":"CVE-2026-114349","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"114349","Ordinal":"1","NoteData":"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.\n\n\nImpact:\n\nAn 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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.","Type":"Description","Title":"Apache Kafka: Denial of service via unbounded memory allocation "}]}}}