{
    "dataType": "CVE_RECORD",
    "dataVersion": "5.2",
    "cveMetadata": {
        "cveId": "CVE-2026-114349",
        "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "state": "PUBLISHED",
        "assignerShortName": "apache",
        "dateReserved": "2026-10-21T08:14:55.090Z",
        "datePublished": "2026-10-28T16:46:54.920Z",
        "dateUpdated": "2026-10-29T13:48:26.738Z"
    },
    "containers": {
        "cna": {
            "providerMetadata": {
                "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
                "shortName": "apache",
                "dateUpdated": "2026-10-29T13:48:26.738Z"
            },
            "title": "Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches",
            "problemTypes": [
                {
                    "descriptions": [
                        {
                            "description": "CWE-789 Memory allocation with excessive size value",
                            "lang": "en",
                            "cweId": "CWE-789",
                            "type": "CWE"
                        }
                    ]
                },
                {
                    "descriptions": [
                        {
                            "description": "CWE-400 Uncontrolled Resource Consumption",
                            "lang": "en",
                            "cweId": "CWE-400",
                            "type": "CWE"
                        }
                    ]
                },
                {
                    "descriptions": [
                        {
                            "description": "CWE-1284 Improper validation of specified quantity in input",
                            "lang": "en",
                            "cweId": "CWE-1284",
                            "type": "CWE"
                        }
                    ]
                }
            ],
            "source": {
                "discovery": "EXTERNAL"
            },
            "affected": [
                {
                    "vendor": "Apache Software Foundation",
                    "product": "Apache Kafka",
                    "packageURL": "pkg:maven/org.apache.kafka/kafka_2.11",
                    "versions": [
                        {
                            "status": "affected",
                            "version": "0.11.0.0",
                            "lessThan": "2.5.0",
                            "versionType": "maven"
                        }
                    ],
                    "defaultStatus": "unaffected",
                    "collectionURL": "https://repo.maven.apache.org/maven2",
                    "packageName": "org.apache.kafka:kafka_2.11"
                },
                {
                    "vendor": "Apache Software Foundation",
                    "product": "Apache Kafka",
                    "packageURL": "pkg:maven/org.apache.kafka/kafka_2.12",
                    "versions": [
                        {
                            "status": "affected",
                            "version": "0.11.0.0",
                            "lessThan": "4.0.0",
                            "versionType": "maven"
                        }
                    ],
                    "defaultStatus": "unaffected",
                    "collectionURL": "https://repo.maven.apache.org/maven2",
                    "packageName": "org.apache.kafka:kafka_2.12"
                },
                {
                    "vendor": "Apache Software Foundation",
                    "product": "Apache Kafka",
                    "packageURL": "pkg:maven/org.apache.kafka/kafka_2.13",
                    "versions": [
                        {
                            "status": "affected",
                            "version": "2.4.0",
                            "lessThanOrEqual": "4.1.2",
                            "versionType": "maven"
                        },
                        {
                            "status": "affected",
                            "version": "4.2.0",
                            "lessThanOrEqual": "4.2.1",
                            "versionType": "maven"
                        },
                        {
                            "status": "affected",
                            "version": "4.3.0",
                            "lessThanOrEqual": "4.3.1",
                            "versionType": "maven"
                        }
                    ],
                    "defaultStatus": "unaffected",
                    "collectionURL": "https://repo.maven.apache.org/maven2",
                    "packageName": "org.apache.kafka:kafka_2.13"
                }
            ],
            "descriptions": [
                {
                    "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.",
                    "lang": "en",
                    "supportingMedia": [
                        {
                            "type": "text/html",
                            "base64": false,
                            "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>"
                        }
                    ]
                }
            ],
            "references": [
                {
                    "url": "https://kafka.apache.org/cve-list",
                    "tags": [
                        "vendor-advisory"
                    ]
                },
                {
                    "url": "https://lists.apache.org/thread/hdy56hrd1h9btf30jb1noswsx32l17dq",
                    "tags": [
                        "mailing-list"
                    ]
                }
            ],
            "metrics": [
                {
                    "other": {
                        "type": "Textual description of severity",
                        "content": {
                            "text": "important"
                        }
                    },
                    "scenarios": [
                        {
                            "lang": "en",
                            "value": "GENERAL"
                        }
                    ]
                }
            ],
            "credits": [
                {
                    "lang": "en",
                    "value": "Peyton Kennedy <pkennedy@endor.ai>",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Trung Nguyen <trungnh@cystack.net>, CyStack",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Bartłomiej Dmitruk <bartek@striga.ai>, Striga",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "임성민 <at_haemil@naver.com>",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Mike Read (GitHub: Michael-JRead)",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Salman Aljardan <salman1aljardan@gmail.com>",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Yuchao Zhang <ndaugoing@gmail.com>",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Yu Bao <yubao@paypal.com>, PayPal Cyber Security Team",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Vamsi K <xh081ix@gmail.com>",
                    "type": "reporter"
                },
                {
                    "lang": "en",
                    "value": "Srinivas Akhil Mallela <srinivasakhil@gmail.com>",
                    "type": "remediation developer"
                },
                {
                    "lang": "en",
                    "value": "Ashish Modi, OpenLogic by Perforce",
                    "type": "reporter"
                }
            ],
            "x_generator": {
                "engine": "Vulnogram 1.0.3"
            }
        },
        "adp": [
            {
                "title": "CVE Program Container",
                "references": [
                    {
                        "url": "http://www.openwall.com/lists/oss-security/2026/10/28/18"
                    }
                ],
                "providerMetadata": {
                    "orgId": "af854a3a-2127-422b-91ae-364da2661108",
                    "shortName": "CVE",
                    "dateUpdated": "2026-10-28T20:06:58.727Z"
                }
            }
        ]
    }
}