CVE-2026-111108 (GCVE-0-2026-111108)
Vulnerability from cvelistv5 – Published: 2026-10-28 16:38 – Updated: 2026-10-28 20:06
VLAI
EPSS
VEX
Title
Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers
Summary
Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field.
Impact:
Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large=
array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization..
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).
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.3.0 , ≤ 4.1.2
(semver)
Affected: 4.2.0 , ≤ 4.2.1 (semver) Affected: 4.3.0 , ≤ 4.3.1 (semver) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-10-28T20:06:52.812Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/10/28/10"
}
],
"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.3.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.2.1",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.3.1",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Mike Read (GitHub: Michael-JRead)"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Izzy Harker \u003ciharker@confluent.io\u003e"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Alyssa Huang \u003cahuang@confluent.io\u003e"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Truc Nguyen \u003ctrnguyen@confluent.io\u003e"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cdiv\u003eApache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u0026nbsp;\u003cspan\u003ecount declared by the sender. That count is checked only against the bytes remaining in the\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequest buffer, which assumes about one byte per element; because most elements need several\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebytes, a request can declare far more elements than the buffer holds and still pass. For a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ekeyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +\u003c/span\u003e\u003cspan\u003e1), so a request of a few tens of megabytes can force a heap allocation several times larger\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebefore any element is read. The pattern is emitted into every generated reader, so it affects\u0026nbsp;\u003c/span\u003e\u003cspan\u003eall Kafka API types with an array field.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eRequest parsing happens before any authorization check. On a listener that does not require\u0026nbsp;\u003cspan\u003eauthentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequests that each declare a very large=\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003earray length and allocate many times their wire size\u0026nbsp;\u003c/span\u003e\u003cspan\u003ein broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u0026nbsp;\u003c/span\u003e\u003cspan\u003econcurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOn listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u0026nbsp;\u003c/span\u003e\u003cspan\u003esince parsing precedes authorization.\u003c/span\u003e\u003cspan\u003e.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u0026nbsp;\u003cspan\u003eand restricting network access to broker listeners reduces, but does not remove, exposure.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u0026nbsp;\u003cspan\u003epre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).\u003c/span\u003e\u003c/div\u003e"
}
],
"value": "Apache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u00a0count declared by the sender. That count is checked only against the bytes remaining in the\u00a0request buffer, which assumes about one byte per element; because most elements need several\u00a0bytes, a request can declare far more elements than the buffer holds and still pass. For a\u00a0keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger\u00a0before any element is read. The pattern is emitted into every generated reader, so it affects\u00a0all Kafka API types with an array field.\u00a0\n\n\nImpact:\n\nRequest parsing happens before any authorization check. On a listener that does not require\u00a0authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u00a0requests that each declare a very large=\n\narray length and allocate many times their wire size\u00a0in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u00a0concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u00a0On listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u00a0since parsing precedes authorization..\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u00a0and restricting network access to broker listeners reduces, but does not remove, exposure.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u00a0pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u00a0and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000)."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of resources without limits or throttling",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-789",
"description": "CWE-789 Memory allocation with excessive size value",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-28T16:38:08.524Z",
"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: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111108",
"datePublished": "2026-10-28T16:38:08.524Z",
"dateReserved": "2026-10-15T15:57:59.889Z",
"dateUpdated": "2026-10-28T20:06:52.812Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-111108",
"date": "2026-10-29",
"epss": "0.00266",
"percentile": "0.1853"
},
"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.3.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.2.1",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.3.1",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"source": "security@apache.org"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Apache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u00a0count declared by the sender. That count is checked only against the bytes remaining in the\u00a0request buffer, which assumes about one byte per element; because most elements need several\u00a0bytes, a request can declare far more elements than the buffer holds and still pass. For a\u00a0keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger\u00a0before any element is read. The pattern is emitted into every generated reader, so it affects\u00a0all Kafka API types with an array field.\u00a0\n\n\nImpact:\n\nRequest parsing happens before any authorization check. On a listener that does not require\u00a0authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u00a0requests that each declare a very large=\n\narray length and allocate many times their wire size\u00a0in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u00a0concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u00a0On listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u00a0since parsing precedes authorization..\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u00a0and restricting network access to broker listeners reduces, but does not remove, exposure.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u00a0pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u00a0and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000)."
}
],
"id": "CVE-2026-111108",
"lastModified": "2026-10-29T15:04:37.187",
"metrics": {},
"published": "2026-10-28T17:17:38.433",
"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/10"
}
],
"sourceIdentifier": "security@apache.org",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-400"
},
{
"lang": "en",
"value": "CWE-770"
},
{
"lang": "en",
"value": "CWE-789"
}
],
"source": "security@apache.org",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Important",
"current_release_date": "2026-10-30T03:50:01+00:00",
"cve": "CVE-2026-111108",
"id": "CVE-2026-111108",
"initial_release_date": "2026-10-28T16:38:08.524000+00:00",
"product_status:known_affected": "1",
"product_status:known_not_affected": "8",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "org.apache.kafka/kafka-clients: Apache kafka: Denial of Service via excessive memory allocation during request parsing",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-111108.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.