Skip to main content
No exploitation reportedAwaiting NVD analysis

CVE-2026-114349

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

No exploitation reported by the sources we read.

  • Published2026-10-28
  • WeaknessCWE-1284 · CWE-400 · CWE-789

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

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. 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.

Timeline

dates in UTC
  1. 2026-10-2816:46CVE publishedCNA

Versions per branch

Products declared by the CNA3 products

As apache, the CNA that assigned this CVE, declared them in the CVE record; versions as written.

  • Apache Software Foundation Apache Kafkaother versions: not affected

    package org.apache.kafka:kafka_2.11https://repo.maven.apache.org/maven2

    Affected
    • ≥ 0.11.0.0, < 2.5.0fixed in 2.5.0maven
  • Apache Software Foundation Apache Kafkaother versions: not affected

    package org.apache.kafka:kafka_2.12https://repo.maven.apache.org/maven2

    Affected
    • ≥ 0.11.0.0, < 4.0.0fixed in 4.0.0maven
  • Apache Software Foundation Apache Kafkaother versions: not affected

    package org.apache.kafka:kafka_2.13https://repo.maven.apache.org/maven2

    Affected
    • ≥ 2.4.0, ≤ 4.1.2no fix statedmaven
    • ≥ 4.2.0, ≤ 4.2.1no fix statedmaven
    • ≥ 4.3.0, ≤ 4.3.1no fix statedmaven

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2026-10-29

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Packages

  • kafkaUbuntu:Pro:18.04:LTSall versions · no fixed version listed

Full record on NVD

Fix

No fix published by the sources we read yet. NVD record

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

  • CISA-ADPSSVC decisionnone2026-11-05
  • CISA-ADPCVSS 3.16.52026-11-05
  • CNAweakness (CWE)CWE-1284, CWE-400, CWE-7892026-10-29
  • NVDweakness (CWE)CWE-1284, CWE-400, CWE-789read 2026-11-05
  • FIRST EPSSEPSS score0.2 %2026-11-05
  • OSVaffected packages—
  • GitHub Advisoriesadvisory—

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Published
2026-10-28
Last Modified
2026-11-05
NVD status
Awaiting Analysis
GitHub Advisory
GHSA-6rr8-5qq5-gq73

Frequently asked questions

What is CVE-2026-114349?

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.

Is CVE-2026-114349 actively exploited?

Active exploitation of CVE-2026-114349 has not been confirmed. Its EPSS score was 0.2% on 2026-11-05, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-114349?

CVE-2026-114349 has a CVSS v3 base score of 6.5 (MEDIUM severity), with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.

Running kafka? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, November 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record