Apache Kafka CVE-2026-111108

Reachability is gated by listener authentication posture, because request parsing (where the over-allocation occurs) runs before any authorization check. On a listener configured without authentication - for example a PLAINTEXT listener - an unauthenticated attacker can trigger the flaw directly. On listeners that require authentication, the attacker needs valid credentials but no specific ACL. The flaw affects all Kafka API types that contain an array field, so no particular API or feature toggle is required beyond network reachability to a broker listener. Limiting factors: network access to a broker listener is needed, authenticated listeners require credentials, and the interim mitigation of lowering socket.request.max.bytes plus restricting network access to broker listeners reduces (but does not eliminate) exposure; the only complete fix is upgrading to 4.2.2, 4.3.2, or 4.4.0.

No CVSS vector, EPSS score, or KEV entry is provided in the input, so quantitative exploitation signals are absent and cannot be compared. The qualitative signals that ARE present point to a credible denial-of-service priority: the flaw is memory-allocation-without-limits (CWE-770) reachable during request parsing, which occurs before any authorization check, and the Apache advisory describes a working reporter demonstration (three concurrent ~90 MB ProduceRequest v3 connections exhausting a 1 GB heap at roughly 8x amplification). The vuln.today decision label is 'this_week', indicating prompt but not emergency remediation. Because parsing precedes authorization, exposure depends heavily on listener configuration: a listener that does not require authentication (e.g. PLAINTEXT) is reachable by a fully unauthenticated attacker, whereas authenticated listeners require valid credentials (but no specific ACL). This is a genuine availability risk for brokers exposing unauthenticated or internet-reachable listeners, but impact is confined to availability - there is no confidentiality or integrity component - so it is a real DoS priority rather than a critical compromise. EPSS and KEV data are missing, not low; absence of those signals should not be read as low real-world risk, and conversely no active exploitation is claimed.

An attacker opens a few concurrent connections to a broker listener and sends requests whose declared array element count is far larger than the bytes actually present, exploiting that the count is validated only against remaining buffer bytes (~1 byte per element) while real elements and the keyed-array ImplicitLinkedHashCollection capacity (2*count+1) consume multiples of that. The Apache reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB broker heap at about 8x amplification, crashing the broker with an OutOfMemoryError. No public exploit code is referenced, only this vendor demonstration.