{"id":"CVE-2026-114349","kind":"vulnerability","aliases":["CVE-2026-114349"],"related":[],"title":"Apache Kafka: crafted compressed batch can crash brokers with memory exhaustion","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.","summary":"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.","severity":"high","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["brokers","compacted-topics","kafka","package","self-hosted"],"not_affected_if":["write-access-restricted-to-trusted-producers"],"how_to_check":"- Check the Kafka broker version against `4.2.2`, `4.3.2`, or `4.4.0`.\n- Check whether `max.decompressed.message.bytes` is set at the broker or topic level, for example with `kafka-configs.sh --describe`.\n- Check whether brokers run with `-XX:+ExitOnOutOfMemoryError`.","fix":"- Upgrade Apache Kafka to `4.2.2`, `4.3.2`, or `4.4.0`.\n- 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.\n- Until upgraded and configured, restrict Write access to trusted producers; quotas and `max.message.bytes` do not mitigate this.","status":"open","published_at":"2026-10-28T17:17:56+00:00","first_seen_at":"2026-10-28T17:34:09+00:00","triaged_at":"2026-10-28T17:35:07+00:00","updated_at":"2026-10-28T17:35:07+00:00","category":"package","confidence":0.8,"triage":{"at":"2026-10-28T17:35:07Z","model":"claude-haiku-5-5","output":{"fix":"- Upgrade Apache Kafka to `4.2.2`, `4.3.2`, or `4.4.0`.\n- 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.\n- Until upgraded and configured, restrict Write access to trusted producers; quotas and `max.message.bytes` do not mitigate this.","reach":"network","title":"Apache Kafka: crafted compressed batch can crash brokers with memory exhaustion","impact":"medium","summary":"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.","category":"package","nicknames":[],"who_cares":["kafka","self-hosted","compacted-topics","brokers"],"confidence":0.8,"needs_auth":"yes","worst_case":"Broker JVM crashes and log compaction stops cluster-wide until the bad record is removed.","analyst_note":"Check the Kafka 4.2.2/4.3.2/4.4.0 release notes and the NVD entry for the CVSS score and affected version ranges, since the sources give no severity or exploit status.","how_to_check":"- Check the Kafka broker version against `4.2.2`, `4.3.2`, or `4.4.0`.\n- Check whether `max.decompressed.message.bytes` is set at the broker or topic level, for example with `kafka-configs.sh --describe`.\n- Check whether brokers run with `-XX:+ExitOnOutOfMemoryError`.","needs_analyst":true,"not_affected_if":["write-access-restricted-to-trusted-producers"],"who_is_affected":"Any Kafka broker that accepts produce requests from principals other than fully trusted producers is exposed, because the attacker needs only Write on a topic. The default value of `max.decompressed.message.bytes` is effectively unlimited, so upgrading alone does not protect a broker. Clusters where all writers are trusted and access is restricted may treat this as lower risk until the upgrade is applied.","user_interaction":"no","needs_special_setup":"no","severity_if_unknown":"high"},"cost_usd":0.000831,"input_tokens":4110,"output_tokens":841,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-114349':14A,17A '-2026':13A,16A '2':162C,388C '4.2.2':350C,458C '4.3.2':351C,459C '4.4.0':353C,461C '90':145C 'accept':263C 'access':442C 'across':326C 'alloc':30B,110C,171C,475C 'alon':372C 'alter':344C 'and/or':360C 'apach':1A,27B,348C,456C 'applic':413C 'appropri':367C 'around':144C 'attack':37B,131C 'attacker-control':130C 'attacker-declar':36B 'attempt':169C 'authent':56B,199C 'avail':122C,337C 'backward':377C 'batch':5A,94C,135C,216C 'bodi':103C,156C,470C 'bound':186C,365C,504C 'broker':8A,18B,29B,69B,86B,89C,167C,208C,241C,255C,312C,359C,392C,419C,463C 'buffer':32B,112C 'byte':121C,146C 'check':43B 'choos':400C 'cleaner':274C,291C,303C,430C 'client/broker':184C 'codec':218C 'comfort':416C 'common':247C 'compact':20B,77B,82B,280C,306C,483C 'compacted-top':19B 'compat':378C 'compress':4A,48B,92C,150C,189C 'compression.type':224C 'condit':324C 'configur':125C,380C,437C,501C 'constrain':139C 'consum':233C,316C 'control':132C 'craft':3A,251C,260C 'crash':7A,64B,207C 'crc':136C,148C 'crc-valid':147C 'cve':12A,15A 'data':340C 'declar':38B,102C,154C,194C,468C 'decod':90C,99C 'decompress':39B,107C,195C,410C,469C 'default':299C,381C,511C 'deni':238C 'differ':219C 'disclos':342C 'disk':269C 'divid':421C 'effect':384C,513C 'encod':230C 'entir':311C 'error':285C 'except':288C 'exhaust':11A 'exitonoutofmemoryerror':245C 'expos':394C 'fetch':235C 'forc':52B,165C 'gib':163C,389C 'handler':66B,211C,428C 'harden':248C 'heap':420C 'host':26B 'impact':197C,335C 'includ':313C 'ingest':265C 'intern':315C 'invalidrecordexcept':496C 'issu':453C 'jvm':70B,256C 'kafka':2A,22B,28B,349C,457C 'largest':408C 'later':275C 'legitim':409C 'level':362C 'limit':126C,177C,182C,397C,439C 'log':81B,273C,305C,482C 'log-clean':272C 'log-compact':481C 'lookup':487C 'max.decompressed.message.bytes':356C,473C 'max.message.bytes':178C,448C 'memori':10A 'mitig':345C,451C 'must':498C 'negat':493C 'number':424C 'offend':330C 'offset':317C 'oper':497C 'outofmemoryerror':54B,173C,283C 'overs':491C 'packag':23B 'path':488C 'per':97C 'per-record':96C 'persist':325C 'princip':200C 'produc':49B,151C,414C,445C,479C 'produce-valid':478C 'protect':508C 'quota':185C,446C 'rais':172C 're':229C 're-encod':228C 'reach':213C 'read':100C,276C 'record':40B,73B,93C,98C,175C,226C,237C,261C,331C,411C,466C 'reject':490C 'remain':393C 'remov':333C 'request':50B,65B,152C,180C,210C,252C,427C 'request-handl':209C,426C 'resolut':454C 'restart':296C,327C 'restrict':440C 'self':25B 'self-host':24B 'serious':258C 'servic':239C 'set':355C,399C,499C 'singl':250C,302C 'size':33B,41B,104C,115C,128C,157C,176C,181C,191C,196C,471C,494C 'slight':405C 'small':47B,143C 'start':242C 'state':320C 'stop':80B,308C 'store':74B 'stream':108C 'suffici':375C 'termin':253C,289C 'thread':212C,292C,304C,431C 'timestamp':486C 'timestamp-lookup':485C 'topic':21B,62B,78B,205C,222C,281C,321C,361C 'transact':319C 'trust':444C 'unlimit':385C,514C 'upgrad':346C,371C,435C 'user':57B 'valid':117C,149C,464C,480C 'valu':366C,386C,402C,505C 'whole':85B 'wire':190C 'workload':370C 'write':59B,202C,441C 'written':267C 'xx':244C","nicknames":[],"mitigations":[],"who_affected":"Any Kafka broker that accepts produce requests from principals other than fully trusted producers is exposed, because the attacker needs only Write on a topic. The default value of `max.decompressed.message.bytes` is effectively unlimited, so upgrading alone does not protect a broker. Clusters where all writers are trusted and access is restricted may treat this as lower risk until the upgrade is applied.","tier":"B","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-28T17:17:56+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-114349","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-114349","severity":null,"published_at":"2026-10-28T17:17:56+00:00","modified_at":"2026-10-28T17:17:56+00:00","first_seen_at":"2026-10-28T17:34:09+00:00","fetched_at":"2026-10-28T17:34:09+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}