Apache Kafka bis 4.1.2/4.2.1/4.3.1 Record Batch Decoder Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.2$0-$5k0.00

Zusammenfassunginfo

Es wurde eine kritische Schwachstelle in Apache Kafka bis 4.1.2/4.2.1/4.3.1 ausgemacht. Dies betrifft einen unbekannten Teil der Komponente Record Batch Decoder. Durch Beeinflussen mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Die Verwundbarkeit wird unter CVE-2026-114349 geführt. Der Angriff kann über das Netzwerk erfolgen. Es ist soweit kein Exploit verfügbar. Als bestmögliche Massnahme wird das Einspielen eines Upgrades empfohlen.

Detailsinfo

In Apache Kafka bis 4.1.2/4.2.1/4.3.1 wurde eine kritische Schwachstelle entdeckt. Hierbei betrifft es ein unbekannter Ablauf der Komponente Record Batch Decoder. Mittels dem Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-770. Die Auswirkungen sind bekannt für die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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.

Das Advisory findet sich auf kafka.apache.org. Die Verwundbarkeit wird seit dem 21.10.2026 als CVE-2026-114349 geführt. Sie ist leicht ausnutzbar. Der Angriff kann über das Netzwerk angegangen werden. Technische Details sind nicht bekannt und ein Exploit zur Schwachstelle ist ebenfalls nicht vorhanden. Die Beschaffenheit der Schwachstelle lässt vermuten, dass ein Exploit momentan zu etwa USD $0-$5k gehandelt werden wird (Preisberechnung vom 28.10.2026). Diese Schwachstelle wird durch das MITRE ATT&CK als Angriffstechnik T1499 bezeichnet.

Ein Aktualisieren auf die Version 4.2.2, 4.3.2 oder 4.4.0 vermag dieses Problem zu lösen.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Produktinfo

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 6.5
VulDB Meta Temp Score: 6.2

VulDB Base Score: 6.5
VulDB Temp Score: 6.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-770 / CWE-400 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kafka 4.2.2/4.3.2/4.4.0

Timelineinfo

21.10.2026 CVE zugewiesen
28.10.2026 +7 Tage Advisory veröffentlicht
28.10.2026 +0 Tage VulDB Eintrag erstellt
28.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: apache.org

Advisory: kafka.apache.org
Status: Bestätigt

CNA: apache
CVE: CVE-2026-114349 (🔒)

GCVE (CVE): GCVE-0-2026-114349
GCVE (VulDB): GCVE-100-428059

Eintraginfo

Erstellt: 28.10.2026 18:17
Anpassungen: 28.10.2026 18:17 (54)
Komplett: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Might our Artificial Intelligence support you?

Check our Alexa App!