CVE Intelligence
Unknown Denial of service

CVE-2026-114349 — Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches

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.

Published Oct 28, 2026 · Updated Oct 29, 2026 · Sources: NIST National Vulnerability Database, CVE Program (cve.org) e CISA ADP, GitHub Security Advisories · CNA: apache

Who exploits it and how urgent it is

A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.

No exploitation signal in the sources consulted so far.
How the score was calculated
  • EPSS 0.2% (30-day exploitation probability)+2

The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).

Triage

Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.

Exploitation
Not confirmed
Not in CISA KEV — an absence of record, not proof it is unexploited.
EPSS FIRST
0.23%
ahead of 14% of scored CVEs · Oct 29, 2026
Affects
Apache Software Foundation
Kafka
CVSS base
—
Score not published yet.

Remediation

Fixes and mitigations documented by the sources — linked to the original advisory.

No fix documented by the sources we poll. That does not mean none exists: check the vendor advisory.

First 24 hours

Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.

  1. Identify exposed assets running the affected vendor/product/version combinations (Apache Software Foundation Kafka).
  2. No fix documented in the sources: reduce exposure and monitor the vendor advisory.
  3. Search available logs for exploit probes matching the vulnerability class (denial of service), errors and authentication anomalies.

Affected scope

Vendor, product and versions as the sources word them.

VendorProductVersionsStatusSource
Apache Software Foundation Kafka ≥ 4.2.0 and ≤ 4.2.1≥ 4.3.0 and ≤ 4.3.1≥ 0.11.0.0 and < 2.5.0≥ 0.11.0.0 and < 4.0.0≥ 2.4.0 and ≤ 4.1.2 Vulnerable CVE Program (cve.org) e CISA ADP

Weakness MITRE

Weakness class according to MITRE’s CWE catalog.

CWE-400 · Uncontrolled Resource Consumption

Other CVEs with this weakness →

Detection

Read off the CVSS vector and the weakness class. Starting points, not tested rules.

  • Track CPU/memory spikes and availability drops correlated with request patterns.
resource metrics

Timeline

What happened to this CVE, newest first.

  • 2026
  • Source status changed · Received → Awaiting Analysis
    Oct 29, 2026 · NIST National Vulnerability Database
  • Affected products removed · 1
    Oct 29, 2026 · CVE Program (cve.org) e CISA ADP
  • Affected products added · apache software foundation/apache kafka
    Oct 29, 2026 · CVE Program (cve.org) e CISA ADP
  • Record published
    Oct 28, 2026
  • Affected products added · apache software foundation/apache kafka
    Oct 28, 2026 · CVE Program (cve.org) e CISA ADP
  • Source status changed · → Received
    Oct 28, 2026 · NIST National Vulnerability Database
  • Record created in this database
    Oct 28, 2026 · Alertas do Telegram
  • CVE published
    Oct 28, 2026 · apache

Source activity

Repeated readings are counted rather than listed.

  • 4× References added · Oct 28, 2026 – Oct 29, 2026
  • 1× Official description updated · Oct 28, 2026 – Oct 28, 2026

References

5 on the record

Elsewhere on this site

Apache Software Foundation
every CVE for this vendor
Denial of service
same class
CWE-400
other pages naming this weakness

Related CVEs (same products)

  • CVE-2026-83525 Apache Kafka: Incorrect boolean operator in FetchSnapshot RPC handler allows authenticated network clients to crash the KRaft controller via a malformed request. 2d
  • CVE-2026-115644 Apache Kafka: Connect Admin REST API Authentication Bypass via Unapplied REST Extensions 2d
  • CVE-2026-116593 Apache Kafka: Kafka Connect configuration provider values exposed via validation REST API endpoint 2d
  • CVE-2026-112375 Apache Kafka: Unauthorized principal can read arbitrary broker files via IncrementalAlterConfigs 2d
  • CVE-2026-111551 Apache Kafka: Denial of service in Kafka Streams and client deserializers via unbounded memory allocation 2d
  • CVE-2026-111496 Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation 2d

Not in any source we poll

Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.

  • No CVSS score published by NVD, the CNA, CISA or GitHub so far.
  • No fixed version, patch or mitigation documented.
  • No CISA SSVC assessment.
  • No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
  • No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
  • No exploit packet captures, log samples, or incident case IDs supplied.

Answered from this record

Text assembled only from the fields above — no additional claims.

What should defenders know first?

CVE-2026-114349 is "Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches", rated Unknown. It affects Kafka (Apache Software Foundation); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. EPSS 0.23% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.

Comments

Moderated technical discussion. Read the community guidelines.

No comments yet.

Sign in or create an account to comment and suggest corrections.