CVE-2026-111108 in Kafka
Riassunto
di VulDB • 28/10/2026
I lettori del protocollo generati dal codice di Apache Kafka dimensionano preventivamente la raccolta di un array in base al conteggio degli elementi dichiarato dal mittente. Tale conteggio viene verificato solo rispetto ai byte rimanenti nel buffer della richiesta, assumendo circa un byte per elemento; poiché la maggior parte degli elementi richiede diversi byte, una richiesta può dichiarare molti più elementi di quanti ne contenga il buffer e superare comunque i controlli. Per gli array con chiave (keyed arrays), il lettore alloca quindi un ImplicitLinkedHashCollection con capacità pari a (2 * count + 1); pertanto, una richiesta di alcune decine di megabyte può forzare un'allocazione heap molte volte superiore prima che venga letto qualsiasi elemento. Questo pattern è presente in ogni lettore generato, interessando tutti i tipi API Kafka con campi array.
Impatto:
L'analisi della richiesta avviene prima di qualsiasi controllo di autorizzazione. Su un listener che non richiede autenticazione (ad esempio PLAINTEXT), un attaccante non autenticato può inviare alcune richieste concorrenti che dichiarano ciascuna una lunghezza dell'array molto elevata, allocando nel heap del broker molte volte la loro dimensione in rete e causando il crash del broker con un OutOfMemoryError. Il reporter ha dimostrato come tre connessioni ProduceRequest (v3) concorrenti di circa 90 MB possano esaurire un heap da 1 GB (~8x amplificazione). Sui listener che richiedono autenticazione, l'attaccante necessita di credenziali valide ma non di ACL specifiche, poiché la parsing precede l'autorizzazione.
Mitigazione:
Aggiornare ad Apache Kafka versione 4.2.2, 4.3.2 o 4.4.0. Fino a quel momento, ridurre il parametro socket.request.max.bytes e limitare l'accesso di rete ai listener del broker riducono, ma non eliminano, la superficie di attacco.
Risoluzione:
A partire da Apache Kafka versioni 4.2.2, 4.3.2 e 4.4.0: i lettori generati limitano l'allocazione preventiva iniziale dell'array a MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) e la aumentano su richiesta; inoltre rifiutano una lunghezza di array dichiarata superiore a MessageUtil.MAX_ARRAY_LENGTH (1.000.000).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.