Vulnerability-Lookup

GHSA-R6FP-X62F-PXFV

Vulnerability from github – Published: 2026-10-28 18:32 – Updated: 2026-10-28 21:31

Details

Impact:

An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL.

Mitigation:

Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation.

Resolution:

From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-111073"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-28T17:17:38Z",
    "severity": null
  },
  "details": "The broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u00a0a client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u00a0it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u00a0decompressed output size, growing a heap buffer until the compressed input is exhausted. A\u00a0small, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u00a0to hundreds of megabytes of broker heap.\n\n\nImpact:\n\n\nAn authenticated client can send a PushTelemetry request with a small compressed payload that\u00a0decompresses to a very large size, consuming broker heap out of proportion to the request\u00a0size. Repeated or concurrent requests can exhaust the broker heap and cause an\u00a0OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u00a0can affect cluster availability. PushTelemetry is available to any authenticated client and is\u00a0not gated by an ACL.\n\n\nMitigation:\n\n\nUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u00a0prevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u00a0lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u00a0partial mitigation.\n\n\nResolution:\n\n\n- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u00a0size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u00a0aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u00a0over-large or highly compressible payload is rejected instead of being fully expanded in\u00a0heap. The decompressed size is therefore bounded by default.",
  "id": "GHSA-r6fp-x62f-pxfv",
  "modified": "2026-10-28T21:31:13Z",
  "published": "2026-10-28T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111073"
    },
    {
      "type": "WEB",
      "url": "https://kafka.apache.org/cve-list"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/28/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-111073 (GCVE-0-2026-111073)

Vulnerability from cvelistv5 – Published: 2026-10-28 16:37 – Updated: 2026-10-28 20:06

Title

Apache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service

Summary

The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap. Impact: An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation. Resolution: - From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default.

Severity

No CVSS data available.

CWE

CWE-409 - Improper handling of highly compressed data (data amplification)
CWE-770 - Allocation of resources without limits or throttling
CWE-400 - Uncontrolled Resource Consumption

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1090 records in the last 180 days details

References

2 references

URL	Tags
https://kafka.apache.org/cve-list	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/1…

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Kafka	Affected: 3.7.0 , ≤ 4.1.2 (semver) Affected: 4.2.0 , ≤ 4.2.1 (semver) Affected: 4.3.0 (semver)

Credits

Dawit Jeong <dev.d4v1d@gmail.com> Apoorv Mittal <apoorvmittal10@gmail.com> Andrew Schofield <aschofield@confluent.io>

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:51.327Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/11"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "3.7.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Dawit Jeong \u003cdev.d4v1d@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Apoorv Mittal \u003capoorvmittal10@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Andrew Schofield \u003caschofield@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eThe broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u0026nbsp;\u003cspan\u003ea client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u0026nbsp;\u003c/span\u003e\u003cspan\u003eit. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u0026nbsp;\u003c/span\u003e\u003cspan\u003edecompressed output size, growing a heap buffer until the compressed input is exhausted. A\u0026nbsp;\u003c/span\u003e\u003cspan\u003esmall, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u0026nbsp;\u003c/span\u003e\u003cspan\u003eto hundreds of megabytes of broker heap.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eAn authenticated client can send a PushTelemetry request with a small compressed payload that\u0026nbsp;\u003cspan\u003edecompresses to a very large size, consuming broker heap out of proportion to the request\u0026nbsp;\u003c/span\u003e\u003cspan\u003esize. Repeated or concurrent requests can exhaust the broker heap and cause an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecan affect cluster availability. PushTelemetry is available to any authenticated client and is\u0026nbsp;\u003c/span\u003e\u003cspan\u003enot gated by an ACL.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u0026nbsp;\u003cspan\u003eprevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u0026nbsp;\u003c/span\u003e\u003cspan\u003elowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u0026nbsp;\u003c/span\u003e\u003cspan\u003epartial mitigation.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003e- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u0026nbsp;\u003cspan\u003esize equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u0026nbsp;\u003c/span\u003e\u003cspan\u003eaborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eover-large or highly compressible payload is rejected instead of being fully expanded in\u0026nbsp;\u003c/span\u003e\u003cspan\u003eheap. The decompressed size is therefore bounded by default.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "The broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u00a0a client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u00a0it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u00a0decompressed output size, growing a heap buffer until the compressed input is exhausted. A\u00a0small, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u00a0to hundreds of megabytes of broker heap.\n\n\nImpact:\n\n\nAn authenticated client can send a PushTelemetry request with a small compressed payload that\u00a0decompresses to a very large size, consuming broker heap out of proportion to the request\u00a0size. Repeated or concurrent requests can exhaust the broker heap and cause an\u00a0OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u00a0can affect cluster availability. PushTelemetry is available to any authenticated client and is\u00a0not gated by an ACL.\n\n\nMitigation:\n\n\nUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u00a0prevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u00a0lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u00a0partial mitigation.\n\n\nResolution:\n\n\n- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u00a0size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u00a0aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u00a0over-large or highly compressible payload is rejected instead of being fully expanded in\u00a0heap. The decompressed size is therefore bounded by default."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-409",
              "description": "CWE-409 Improper handling of highly compressed data (data amplification)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource   Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:58.482Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111073",
    "datePublished": "2026-10-28T16:37:58.482Z",
    "dateReserved": "2026-10-15T13:40:49.926Z",
    "dateUpdated": "2026-10-28T20:06:51.327Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted