CVE-2026-111073 (GCVE-0-2026-111073)
Vulnerability from cvelistv5 – Published: 2026-10-28 16:37 – Updated: 2026-10-28 20:06
VLAI
EPSS
VEX
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
Assigner
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 | CPE status | |
|---|---|---|---|---|
| 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) |
guessed |
{
"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",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-111073",
"date": "2026-10-30",
"epss": "0.00204",
"percentile": "0.10377"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"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"
}
]
}
],
"source": "security@apache.org"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"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."
}
],
"id": "CVE-2026-111073",
"lastModified": "2026-10-29T15:43:45.047",
"metrics": {},
"published": "2026-10-28T17:17:38.300",
"references": [
{
"source": "security@apache.org",
"url": "https://kafka.apache.org/cve-list"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "http://www.openwall.com/lists/oss-security/2026/10/28/11"
}
],
"sourceIdentifier": "security@apache.org",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-400"
},
{
"lang": "en",
"value": "CWE-409"
},
{
"lang": "en",
"value": "CWE-770"
}
],
"source": "security@apache.org",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-10-30T00:29:18+00:00",
"cve": "CVE-2026-111073",
"id": "CVE-2026-111073",
"initial_release_date": "2026-10-28T16:37:58.482000+00:00",
"product_status:known_affected": "9",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "org.apache.kafka/kafka-clients: Apache Kafka: Denial of Service via unbounded telemetry payload decompression",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-111073.json",
"version": "3"
}
}
}
Loading…
Loading…
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.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
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
Loading timeline…
Loading…
Loading…
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.
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.
Loading…
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.