Netty CVE-2026-93572: dwa limity, a heap nadal można wyczerpać

RedisArrayAggregator w Netty miał już limity maxElements i maxNestedArrayDepth — a mimo to heap dało się wyczerpać. Powód: eager allocation ArrayList(length) sprawiała, że lokalne limity mogły się mnożyć do dużego globalnego kosztu pamięci. To modelowy incomplete fix: dwa poprawne limity, jeden niebezpieczny efekt złożenia.

CVE-2026-93572 (Netty, RedisArrayAggregator): mimo maxElements i maxNestedArrayDepth eager ArrayList(length) per poziom → multiplicative memory cost → heap exhaustion → DoS.

Fix: 4.2.18.Final i 4.1.138.Final. Verification: version check + test z zagnieżdżonymi nagłówkami + shaded Netty.

Attack path

untrusted RESP -> nested array headers -> eager capacity allocation per level -> multiplicative memory cost -> heap exhaustion -> DoS

Incomplete fix

Security invariant powinien brzmieć: niezaufany input nie może wymusić nieproporcjonalnej alokacji. Ograniczenie każdej osi osobno (liczba elementów, głębokość zagnieżdżenia) nie gwarantuje ograniczenia całkowitego kosztu — bo koszt jest iloczynem, nie sumą. To dlatego dwa „rozsądne” limity nadal pozwalały na heap exhaustion.

Remediation

Upstream wskazuje patched versions 4.2.18.Final i 4.1.138.Final.

Verification

Oprócz version check warto wykonać test z zagnieżdżonymi nagłówkami i obserwować heap. Sprawdź shaded Netty oraz realne użycie RedisDecoder/RedisArrayAggregator — jeśli aplikacja nie parsuje niezaufanego RESP, ekspozycja jest inna niż w bramce przyjmującej ruch z zewnątrz.

Powiązane na blogu

Netty CVE-2026-93568 — drugi finding z tego samego okna
Excelize: spinCount CPU DoS — koszt zasobów jako podatność

Źródło

Netty GHSA-r4xx-7fpg-j8xg — github.com

Nota redakcyjna: stan informacji 27 września 2026. CVE-2026-93572 (Netty, RedisArrayAggregator, incomplete fix). Ekspozycja zależy od tego, czy aplikacja parsuje niezaufany RESP.