Apache Kafka’s code‑generated protocol readers pre‑allocate array space based solely on the element count declared by a sender, assuming one byte per element. Because most elements require more bytes, a request can declare many more elements than actually exist in the request buffer. For keyed arrays, the reader allocates a linked hash collection with capacity (2*count+1), which can provoke a heap allocation far larger than the request size, before any element is read. If an attacker sends such a request, the broker can exhaust its heap and throw an OutOfMemoryError, terminating the process and rendering the service unavailable. The vulnerability is a classic case of insufficient input validation and unchecked resource allocation.

The flaw affects all versions of Apache Kafka released by the Apache Software Foundation. The problem is present in every protocol reader generated for Kafka API types that contain an array field. Affected versions include all releases prior to 4.2.2, 4.3.2, and 4.4.0. The specific versions that contain the fix are 4.2.2, 4.3.2, and 4.4.0, which limit the pre‑allocation to 1,000 items and reject any declared array length above 1,000,000.

The CVSS score is not provided, but the vulnerability can be leveraged by an unauthenticated attacker against any listener that does not require authentication (e.g., PLAINTEXT), or by an authenticated attacker against any listener that does require credentials, because request parsing occurs before authorization checks. The attacker may send several concurrent requests that each declare a large array length, causing the broker to allocate large temporal structures and crash. EPSS is not available and the weakness is not listed in the CISA KEV catalog, yet the impact is a remote denial of service with high potential impact on availability. The exploit requires only the ability to send crafted requests to an open broker listener; no special privileges or target‑specific configuration are needed beyond network access to the broker endpoint.