Skip to main content
No exploitation reportedAwaiting NVD analysis

CVE-2026-111115

Apache Kafka: Broker OutOfMemoryError via tagged-field allocation amplification in flexible protocol request parsing

No exploitation reported by the sources we read.

  • Published2026-10-28

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. 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 bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.

Timeline

dates in UTC
  1. 2026-10-2816:44CVE publishedCNA

Versions per branch

Products declared by the CNA

As apache, the CNA that assigned this CVE, declared them in the CVE record; versions as written. NVD lists no product for this CVE yet: this is the only product data so far.

  • Apache Software Foundation Apache Kafkaother versions: not affected

    package org.apache.kafka:kafkahttps://repo.maven.apache.org/maven2

    Affected
    • ≥ 2.4.0, ≤ 4.1.2no fix statedsemver
    • ≥ 4.2.0, ≤ 4.2.1no fix statedsemver
    • ≥ 4.3.0, ≤ 4.3.1no fix statedsemver

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2026-10-28

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Vendor advisories

  • CVE-2026-111115 Red Hat Product Security7 known affected

    org.apache.kafka/kafka-clients: Apache Kafka: Denial of Service via uncontrolled memory allocation in flexible request headers

    kafka-clients as a component of Red Hat build of Apache Camel 4 for Quarkus 3 · kafka-clients as a component of Red Hat build of Apache Camel for Spring Boot 4 · kafka-clients as a component of Red Hat build of Apicurio Registry 3 · +4 more

Full record on NVD

Fix

  1. Workaround from the vendor Red Hat Product Security CVE-2026-111115 · 7 productsRestrict network exposure of Kafka broker listener ports and reduce the maximum permitted request frame size: 1. Restrict broker network access: Limit connectivity to broker listeners (default port 9092/tcp) to trusted clients and internal subnets using firewall rules: ``` firewall-cmd --permanent…
  2. No fix available, says the vendor Red Hat Product Security CVE-2026-111115 · 1 productFix deferred
  3. No fix available, says the vendor Red Hat Product Security CVE-2026-111115 · 6 productsAffected

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Published
2026-10-28
Last Modified
2026-11-05
NVD status
Awaiting Analysis
GitHub Advisory
GHSA-7xcv-9qfj-9q57

Frequently asked questions

What is CVE-2026-111115?

Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. 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 bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.

Is CVE-2026-111115 actively exploited?

Active exploitation of CVE-2026-111115 has not been confirmed. Its EPSS score was 0.2% on 2026-11-05, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-111115?

CVE-2026-111115 has a CVSS v3 base score of 9.1 (CRITICAL severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H.

Running kafka-clients? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, November 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record