GHSA-6RR8-5QQ5-GQ73

Vulnerability from github – Published: 2026-10-28 18:32 – Updated: 2026-10-29 15:30
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-114349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-28T17:17:56Z",
    "severity": null
  },
  "details": "When a broker decodes a compressed record batch, the per-record decoder reads a declared body\u00a0size from the decompressed stream and allocates a buffer of that size before validating it\u00a0against the bytes available or any configured limit. The size is attacker-controlled, and the\u00a0batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce\u00a0request can declare a body size of up to about 2 GiB and force the broker to attempt that\u00a0allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request\u00a0size limit, and client/broker quotas bound only the compressed wire size, not the declared\u00a0decompressed size.\n\n\nImpact:\n\nAn authenticated principal with Write on a topic can crash broker request-handler threads\u00a0(reached when a batch\u0027s codec differs from the topic\u0027s compression.type and records are\u00a0re-encoded) and any consumer that fetches the record, denying service. On brokers started\u00a0with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the\u00a0broker JVM. More seriously, a\u00a0crafted record\u00a0\u00a0is accepted at ingest and written to disk; when the log-cleaner later reads it\u00a0on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner\u00a0thread, which is not restarted. With the default of a single cleaner thread, log compaction\u00a0then stops for the entire broker, including the internal __consumer_offsets and\u00a0__transaction_state topics, and the condition persists across restarts until the offending\u00a0record 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\u00a0broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is\u00a0not sufficient: for backward compatibility this configuration defaults to an effectively\u00a0unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a\u00a0value at or slightly above the largest legitimate decompressed record your applications\u00a0produce, and comfortably below the broker heap divided by the number of request-handler and\u00a0cleaner threads. Until you can upgrade and configure the limit, restrict Write access to\u00a0trusted 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\u0027s declared decompressed\u00a0body size against max.decompressed.message.bytes before allocating, on the produce-validation,\u00a0log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with\u00a0InvalidRecordException. Operators must set this configuration to a bounded value to be protected,\u00a0as its default is effectively unlimited.",
  "id": "GHSA-6rr8-5qq5-gq73",
  "modified": "2026-10-29T15:30:40Z",
  "published": "2026-10-28T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114349"
    },
    {
      "type": "WEB",
      "url": "https://kafka.apache.org/cve-list"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/hdy56hrd1h9btf30jb1noswsx32l17dq"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/28/18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.