CVE-2026-111108

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-111108", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "state": "PUBLISHED", "assignerShortName": "apache", "dateReserved": "2026-10-15T15:57:59.889Z", "datePublished": "2026-10-28T16:38:08.524Z", "dateUpdated": "2026-11-05T19:16:48.026Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-10-28T16:38:08.524Z"}, "title": "Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers", "problemTypes": [{"descriptions": [{"description": "CWE-770 Allocation of resources without limits or throttling", "lang": "en", "cweId": "CWE-770", "type": "CWE"}]}, {"descriptions": [{"description": "CWE-789 Memory allocation with excessive size value", "lang": "en", "cweId": "CWE-789", "type": "CWE"}]}, {"descriptions": [{"description": "CWE-400 Uncontrolled Resource Consumption", "lang": "en", "cweId": "CWE-400", "type": "CWE"}]}], "source": {"discovery": "EXTERNAL"}, "affected": [{"vendor": "Apache Software Foundation", "product": "Apache Kafka", "packageURL": "pkg:maven/org.apache.kafka/kafka", "versions": [{"status": "affected", "version": "3.3.0", "lessThanOrEqual": "4.1.2", "versionType": "semver"}, {"status": "affected", "version": "4.2.0", "lessThanOrEqual": "4.2.1", "versionType": "semver"}, {"status": "affected", "version": "4.3.0", "lessThanOrEqual": "4.3.1", "versionType": "semver"}], "defaultStatus": "unaffected", "collectionURL": "https://repo.maven.apache.org/maven2", "packageName": "org.apache.kafka:kafka"}], "descriptions": [{"value": "Apache Kafka's code-generated protocol readers pre-size an array's 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).", "lang": "en", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<div>Apache Kafka's code-generated protocol readers pre-size an array's collection from the element&nbsp;<span>count declared by the sender. That count is checked only against the bytes remaining in the&nbsp;</span><span>request buffer, which assumes about one byte per element; because most elements need several&nbsp;</span><span>bytes, a request can declare far more elements than the buffer holds and still pass. For a&nbsp;</span><span>keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +</span><span>1), so a request of a few tens of megabytes can force a heap allocation several times larger&nbsp;</span><span>before any element is read. The pattern is emitted into every generated reader, so it affects&nbsp;</span><span>all Kafka API types with an array field.&nbsp;</span></div><br><div>Impact:</div><div>Request parsing happens before any authorization check. On a listener that does not require&nbsp;<span>authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent&nbsp;</span><span>requests that each declare a very large=</span></div><div><span>array length and allocate many times their wire size&nbsp;</span><span>in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three&nbsp;</span><span>concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).&nbsp;</span><span>On listeners that require authentication, the attacker needs valid credentials but no specific ACL,&nbsp;</span><span>since parsing precedes authorization.</span><span>.</span></div><br><div>Mitigation:</div><div>Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes&nbsp;<span>and restricting network access to broker listeners reduces, but does not remove, exposure.</span></div><br><div>Resolution:</div><div>From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array&nbsp;<span>pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,&nbsp;</span><span>and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).</span></div>"}]}], "references": [{"url": "https://kafka.apache.org/cve-list", "tags": ["vendor-advisory"]}], "metrics": [{"other": {"type": "Textual description of severity", "content": {"text": "important"}}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "credits": [{"lang": "en", "value": "Mike Read (GitHub: Michael-JRead)", "type": "reporter"}, {"lang": "en", "value": "Izzy Harker <iharker@confluent.io>", "type": "remediation developer"}, {"lang": "en", "value": "Alyssa Huang <ahuang@confluent.io>", "type": "remediation developer"}, {"lang": "en", "value": "Truc Nguyen <trnguyen@confluent.io>", "type": "remediation developer"}], "x_generator": {"engine": "Vulnogram 1.0.3"}}, "adp": [{"title": "CVE Program Container", "references": [{"url": "http://www.openwall.com/lists/oss-security/2026/10/28/10"}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2026-10-28T20:06:52.812Z"}}, {"metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}}, {"other": {"type": "ssvc", "content": {"timestamp": "2026-11-05T19:16:37.186580Z", "id": "CVE-2026-111108", "options": [{"Exploitation": "none"}, {"Automatable": "yes"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-05T19:16:48.026Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "http://www.openwall.com/lists/oss-security/2026/10/28/10"}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2026-10-28T20:06:52.812Z"}}, {"title": "CISA ADP Vulnrichment", "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}}, {"other": {"type": "ssvc", "content": {"id": "CVE-2026-111108", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "yes"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-11-05T19:16:37.186580Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-05T19:16:26.841Z"}}], "cna": {"title": "Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers", "source": {"discovery": "EXTERNAL"}, "credits": [{"lang": "en", "type": "reporter", "value": "Mike Read (GitHub: Michael-JRead)"}, {"lang": "en", "type": "remediation developer", "value": "Izzy Harker <iharker@confluent.io>"}, {"lang": "en", "type": "remediation developer", "value": "Alyssa Huang <ahuang@confluent.io>"}, {"lang": "en", "type": "remediation developer", "value": "Truc Nguyen <trnguyen@confluent.io>"}], "metrics": [{"other": {"type": "Textual description of severity", "content": {"text": "important"}}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"vendor": "Apache Software Foundation", "product": "Apache Kafka", "versions": [{"status": "affected", "version": "3.3.0", "versionType": "semver", "lessThanOrEqual": "4.1.2"}, {"status": "affected", "version": "4.2.0", "versionType": "semver", "lessThanOrEqual": "4.2.1"}, {"status": "affected", "version": "4.3.0", "versionType": "semver", "lessThanOrEqual": "4.3.1"}], "packageURL": "pkg:maven/org.apache.kafka/kafka", "packageName": "org.apache.kafka:kafka", "collectionURL": "https://repo.maven.apache.org/maven2", "defaultStatus": "unaffected"}], "references": [{"url": "https://kafka.apache.org/cve-list", "tags": ["vendor-advisory"]}], "x_generator": {"engine": "Vulnogram 1.0.3"}, "descriptions": [{"lang": "en", "value": "Apache Kafka's code-generated protocol readers pre-size an array's 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).", "supportingMedia": [{"type": "text/html", "value": "<div>Apache Kafka's code-generated protocol readers pre-size an array's collection from the element&nbsp;<span>count declared by the sender. That count is checked only against the bytes remaining in the&nbsp;</span><span>request buffer, which assumes about one byte per element; because most elements need several&nbsp;</span><span>bytes, a request can declare far more elements than the buffer holds and still pass. For a&nbsp;</span><span>keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +</span><span>1), so a request of a few tens of megabytes can force a heap allocation several times larger&nbsp;</span><span>before any element is read. The pattern is emitted into every generated reader, so it affects&nbsp;</span><span>all Kafka API types with an array field.&nbsp;</span></div><br><div>Impact:</div><div>Request parsing happens before any authorization check. On a listener that does not require&nbsp;<span>authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent&nbsp;</span><span>requests that each declare a very large=</span></div><div><span>array length and allocate many times their wire size&nbsp;</span><span>in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three&nbsp;</span><span>concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).&nbsp;</span><span>On listeners that require authentication, the attacker needs valid credentials but no specific ACL,&nbsp;</span><span>since parsing precedes authorization.</span><span>.</span></div><br><div>Mitigation:</div><div>Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes&nbsp;<span>and restricting network access to broker listeners reduces, but does not remove, exposure.</span></div><br><div>Resolution:</div><div>From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array&nbsp;<span>pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,&nbsp;</span><span>and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).</span></div>", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-770", "description": "CWE-770 Allocation of resources without limits or throttling"}]}, {"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-789", "description": "CWE-789 Memory allocation with excessive size value"}]}, {"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-400", "description": "CWE-400 Uncontrolled Resource Consumption"}]}], "providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-10-28T16:38:08.524Z"}}}, "cveMetadata": {"cveId": "CVE-2026-111108", "state": "PUBLISHED", "dateUpdated": "2026-11-05T19:16:48.026Z", "dateReserved": "2026-10-15T15:57:59.889Z", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "datePublished": "2026-10-28T16:38:08.524Z", "assignerShortName": "apache"}, "dataVersion": "5.2"}

{"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's code-generated protocol readers pre-size an array's 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-11-05T20:17:41.390", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 9.1, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 5.2, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-111108", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-11-05T19:16:37.186580Z", "version": "2.0.3"}}]}, "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"}]}

{"bugzilla": {"description": "org.apache.kafka/kafka-clients: Apache kafka: Denial of Service via excessive memory allocation during request parsing", "id": "2562960", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2562960"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.5", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-770", "details": ["Apache Kafka's code-generated protocol readers pre-size an array's 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\nImpact:\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=\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..\nMitigation:\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.\nResolution:\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).", "A flaw was found in Apache Kafka. Due to improper input validation during protocol request parsing, the service pre-allocates disproportionately large memory collections based on the sender's declared array element count without verifying that the request buffer contains sufficient data. A remote attacker can exploit this vulnerability by sending requests specifying excessively large array lengths, forcing substantial memory allocation before authorization checks occur. This excessive allocation can exhaust broker heap memory and crash the service, resulting in a Denial of Service (DoS)."], "mitigation": {"lang": "en:us", "value": "Red Hat is not aware of any available mitigation for this issue. Customers are advised to apply the relevant security updates as they become available."}, "name": "CVE-2026-111108", "package_state": [{"cpe": "cpe:/a:redhat:serverless:1", "fix_state": "Not affected", "package_name": "openshift-serverless-1/kn-ekb-dispatcher-rhel9", "product_name": "OpenShift Serverless"}, {"cpe": "cpe:/a:redhat:serverless:1", "fix_state": "Not affected", "package_name": "openshift-serverless-1/kn-ekb-receiver-rhel9", "product_name": "OpenShift Serverless"}, {"cpe": "cpe:/a:redhat:camel_quarkus:3", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat build of Apache Camel 4 for Quarkus 3"}, {"cpe": "cpe:/a:redhat:camel_spring_boot:4", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat build of Apache Camel for Spring Boot 4"}, {"cpe": "cpe:/a:redhat:apicurio_registry:3", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat build of Apicurio Registry 3"}, {"cpe": "cpe:/a:redhat:debezium:3", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat build of Debezium 3"}, {"cpe": "cpe:/a:redhat:quarkus:3", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat build of Quarkus"}, {"cpe": "cpe:/a:redhat:jboss_fuse:7", "fix_state": "Not affected", "package_name": "kafka-clients", "product_name": "Red Hat Fuse 7"}, {"cpe": "cpe:/a:redhat:amq_streams:3", "fix_state": "Affected", "package_name": "kafka-clients", "product_name": "streams for Apache Kafka 3"}], "public_date": "2026-10-28T16:38:08Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-111108\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-111108\nhttps://kafka.apache.org/cve-list"], "statement": "This flaw is in Apache Kafka broker request parsing: generated protocol readers can pre-allocate large heap collections from an attacker-controlled array length before authorization, enabling out-of-memory denial of service. Red Hat rates it Important for deployments that expose Kafka broker listeners.\nMost Red Hat offerings listed against kafka-clients are not affected because they do not run an Apache Kafka broker that accepts Kafka API requests from clients. Quarkus, Camel, Fuse, Debezium, Service Registry, and related cloud-service images use kafka-clients only as producers or consumers against an external cluster. OpenShift Serverless kn-ekb dispatcher/receiver components are a Knative Eventing Kafka data plane (HTTP plus kafka-clients) and are not Kafka brokers, so they are not exposed to this request-parse path. The Red Hat product that remains affected is AMQ Streams, which ships the Kafka broker and falls within the upstream affected version range.", "threat_severity": "Important"}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[3.3.0,4.1.2]"}}, {"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[4.2.0,4.2.1]"}}, {"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[4.3.0,4.3.1]"}}], "enrichment": {"confidence": 100.0, "confidence_source": "manual", "scores": [{"score": 100.0, "source": "manual"}]}, "original": {"product": "Apache Kafka", "source": "cna", "vendor": "Apache Software Foundation"}, "product": "kafka", "vendor": "apache"}], "created": "2026-10-28T17:30:15.427140+00:00", "updated": "2026-11-05T21:30:17.960261+00:00", "vendors": ["apache", "apache$PRODUCT$kafka"]}