Apache Kafka up to 4.1.2/4.2.1/4.3.1 Code-Generated Readers allocation of resources

Summaryinfo

A vulnerability labeled as problematic has been found in Apache Kafka up to 4.1.2/4.2.1/4.3.1. The affected element is an unknown function of the component Code-Generated Readers. Such manipulation leads to allocation of resources. This vulnerability is referenced as CVE-2026-111115. It is possible to launch the attack remotely. No exploit is available. The affected component should be upgraded.

Detailsinfo

A vulnerability, which was classified as problematic, has been found in Apache Kafka up to 4.1.2/4.2.1/4.3.1. Affected by this issue is an unknown part of the component Code-Generated Readers. The manipulation with an unknown input leads to a allocation of resources vulnerability. Using CWE to declare the problem leads to CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. Impacted is availability. CVE summarizes:

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.

The advisory is shared for download at kafka.apache.org. This vulnerability is handled as CVE-2026-111115 since 10/15/2026. The exploitation is known to be easy. The attack may be launched remotely. No form of authentication is required for exploitation. There are neither technical details nor an exploit publicly available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 10/28/2026). The MITRE ATT&CK project declares the attack technique as T1499.

Upgrading to version 4.2.2, 4.3.2 or 4.4.0 eliminates this vulnerability.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• Apache

Name

• Kafka

Version

• 4.1.0
• 4.1.1
• 4.1.2
• 4.2.0
• 4.2.1
• 4.3.0
• 4.3.1

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion