EUVD-2026-112176
GHSA-6rr8-5qq5-gq73
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as principal with topic Write
-
DeliveryCraft ~90-byte CRC-valid compressed produce request
-
ExploitDeclare ~2 GiB decompressed body size
-
ExecutionBroker allocates buffer before validation
-
PersistOutOfMemoryError crashes handler/cleaner thread
-
ImpactBroker DoS and halted log compaction
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Requires an authenticated principal holding Write permission on a topic (per the vendor Impact text; note no CVSS vector is provided to confirm this formally). The request-handler-thread crash is reached only when a batch's codec differs from the topic's configured compression.type so records are re-encoded. The persistent log-compaction outage requires the poisoned record to land on a compacted topic, where the single default cleaner thread dies and is not restarted, stopping compaction broker-wide until the record is removed. Immediate full-broker JVM termination additionally requires the common hardening flag -XX:+ExitOnOutOfMemoryError. Critically, upgrading alone does not remove exposure: max.decompressed.message.bytes defaults to an effectively unlimited (~2 GiB) value, so a patched broker remains vulnerable until an operator sets a bounded limit. Quotas, max.message.bytes, and request-size limits do NOT mitigate this, as they bound only the compressed wire size. |
| Impact | This is a medium-urgency availability vulnerability (CWE-789, excessive memory allocation) whose practical risk is moderated by its access requirement and limited impact. No CVSS vector is provided in the input (NVD/vendor score is N/A), so attack-vector, complexity, and privilege metrics cannot be confirmed from a published vector; the vendor Impact text explicitly states an authenticated principal with Write permission on a topic is required, which points to a privileged rather than fully anonymous attacker. No EPSS score and no KEV listing are provided, and no PoC or exploit reference appears among the references (only the Apache CVE-list advisory), so by the available signals there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_week', indicating a prompt-but-not-emergency priority, consistent with a no-KEV/no-EPSS availability bug. The notable aggravating factors are design-level, not exploitation-maturity: a tiny (~90-byte) CRC-valid request can force a ~2 GiB allocation, the fix is ineffective unless operators also set max.decompressed.message.bytes (default is effectively unlimited), and a single crafted record written at ingest can permanently stop log compaction (including __consumer_offsets and __transaction_state) until the record is removed, persisting across restarts. Net: a real priority for Kafka operators to patch and configure this week, but not a mass-exploitation emergency - impact is availability only, access is authenticated, and no exploit maturity is indicated. |
| Exploit ScenarioDerived | An authenticated producer with Write permission on any topic sends a small, CRC-valid compressed produce request in which a per-record body size is declared as up to ~2 GiB. The broker allocates the declared buffer before validating it, raising OutOfMemoryError; the same poisoned record, once written to disk on a compacted topic, later crashes the single log-cleaner thread and halts compaction broker-wide. No public exploit code is identified in the provided data, but the technique is straightforward given the detailed vendor description. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit a roughly 90-byte, CRC-valid compressed produce request that declares a decompressed record body of up to about 2 GiB, forcing the broker to attempt that allocation and raise OutOfMemoryError. The flaw is reachable on the produce-validation path when a batch's codec differs from the topic's configured compression.type and records are re-encoded, and a crafted record accepted at ingest can also kill the single default log-cleaner thread when it is later read on a compacted topic, stopping compaction broker-wide (including __consumer_offsets and __transaction_state) across restarts until the record is removed; because OutOfMemoryError is an Error rather than an Exception, the cleaner thread is not restarted. Impact is availability only - no data disclosure or modification - and no public exploit code has been identified at time of analysis. Critically, patching alone does not close exposure: the new max.decompressed.message.bytes setting defaults to an effectively unlimited (~2 GiB) value for backward compatibility, so operators must both upgrade and configure a bounded limit.
RemediationAI
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, which validate 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 reject oversized or negative sizes with InvalidRecordException. Upgrading alone is not sufficient: max.decompressed.message.bytes defaults to an effectively unlimited value (about 2 GiB) for backward compatibility, so a patched broker stays exposed until the operator sets a bounded value at the broker and/or topic level - choose a limit at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below broker heap divided by the number of request-handler and cleaner threads. Until both steps are complete, restrict Write access on topics to trusted producers; quotas, max.message.bytes, and request-size limits do not mitigate this issue because they bound only the compressed wire size. The vendor advisory is at https://kafka.apache.org/cve-list.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-789 (memory allocation with excessive size value) in the broker's per-record decoder for compressed record batches. When decoding a compressed batch, the broker reads an attacker-declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes actually available or against any configured limit; the batch CRC does not constrain the declared size, so a tiny valid request can request a multi-gigabyte allocation. The existing controls - the record size limit max.message.bytes, the request size limit, and client/broker quotas - all bound only the compressed wire size, leaving the declared decompressed size unbounded. The failure surfaces on three broker code paths: produce validation (reached when a batch's codec differs from the topic's compression.type so records are re-encoded), log compaction, and timestamp lookup. Because the condition manifests as an OutOfMemoryError, it can terminate the request-handler thread or, with -XX:+ExitOnOutOfMemoryError enabled (a common hardening), the whole broker JVM; on the compaction path it terminates the log-cleaner thread, which Kafka does not restart, disabling compaction for the entire broker under the default single-cleaner-thread configuration. The affected component family is tracked as cpe:2.3:a:apache_software_foundation:apache_kafka, with the vendor's advisory published in the Kafka CVE list.
Know when Apache Kafka gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Remote over the Kafka protocol (AV:N) with low complexity; vendor states topic Write is required (PR:L); no user interaction; availability-only impact (A:H, C:N/I:N).
Primary rating from Vendor (apache).
DescriptionCVE.org
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.
Executive ViewAI
A high-severity vulnerability in Apache Kafka (CVE-2026-114349) allows an authenticated user with write access to a topic to crash brokers via memory exhaustion, disrupting availability across the Kafka cluster. This could halt critical data streaming and transaction processing, impacting business operations that depend on Kafka. Leadership should prioritize mitigation as no public exploit code is known, but the risk of insider or compromised-account abuse remains.
No vendor-released patch identified at time of analysis. Interim mitigations include restricting topic Write permissions to trusted users, monitoring for anomalous produce requests, and configuring broker memory limits or disabling recompression where feasible.
Threat Intelligence Overview
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
More in Apache Kafka
View allApache Kafka 4.1.0 and 4.1.1 accept forged JWT tokens without signature validation, allowing remote unauthenticated atta
Apache Kafka's NetworkClient component logs entire request and response payloads at DEBUG level, exposing sensitive auth
Improper authorization in Apache Kafka 4.0.0-4.3.0 arises from a discrepancy between the documented ACL requirement and
Apache Kafka brokers that have an authorizer enabled will read a file or environment variable from the broker host and r
Kafka Connect workers leak plaintext secrets through the REST API's /connector-plugins/{connector-type}/config/validate
Authentication bypass in Apache Kafka Connect's isolated admin REST API allows unauthenticated network attackers to read
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force m
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an in
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array eleme
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714)
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endp
Exploit-DB