CVE-2026-76816

Netty przed wersjami 4.2.13.Final i 4.1.133.Final ma podatność w Lz4FrameDecoder, który alokuje ByteBuf o rozmiarze decompressedLength, co może prowadzić do niekontrolowanego przydziału pamięci. Atakujący może wykorzystać 21-bajtowy nagłówek oraz skompresowane dane, aby wymusić tę alokację.

Netty, asynchroniczny framework aplikacji sieciowych, ma problem w wersjach od 4.2.0.Final do 4.2.13.Final, gdzie transport epoll nie wykrywa i nie zamyka połączeń TCP, które otrzymują RST po częściowym zamknięciu. To prowadzi do nieaktualnych kanałów, które nigdy nie są usuwane oraz w niektórych ścieżkach kodu do 100% obciążenia CPU w wątku pętli zdarzeń.

W Netty w wersjach 4.0.x przed 4.0.37.Final oraz 4.1.x przed 4.1.1.Final występuje podatność w pliku OpenSslEngine.java, która pozwala zdalnym atakującym na spowodowanie odmowy usługi poprzez nieskończoną pętlę.

Netty to asynchroniczny, sterowany zdarzeniami framework do tworzenia aplikacji sieciowych. Przed wersjami 4.1.137.Final i 4.2.17.Final funkcja io.netty.handler.ssl.SslClientHelloHandler#decode sprawdza niewłaściwy offset przed odczytaniem czterobajtowego nagłówka TLS handshake, więc ClientHello, którego nagłówek handshake obejmuje wiele rekordów, może spowodować IndexOutOfBoundsException i wywołać select(ctx, null). To wybiera domyślny SslContext zamiast kontekstu specyficznego dla SNI. We wdrożeniach, gdzie per-SNI clientAuth=REQUIRE jest jedyną bramą wzajemnego TLS, a domyślny SslContext używa clientAuth=NONE lub clientAuth=OPTIONAL i nie ma weryfikacji certyfikatów na poziomie aplikacji, nieuwierzytelniony zdalny atakujący może ominąć wymóg wzajemnego TLS chronionej trasy. Problem jest naprawiony w wersjach 4.1.137.Final i 4.2.17.Final.

Netty w wersjach 4.2.0.Final do 4.2.15.Final oraz 4.1.0.Final do 4.1.135.Final zawiera podatność w XmlDecoder, gdzie dostarczenie danych XML z deklaracją DOCTYPE do AsyncXMLInputFactory bez konfiguracji bezpieczeństwa może aktywować obsługę DTD i encji, stwarzając ryzyko XML External Entity (XXE).

Netty (io.netty:netty-codec-socks) w wersjach od 4.2.0.Final do 4.2.16.Final oraz od 4.1.x do 4.1.136.Final zawiera podatności na wstrzykiwanie bajtów null, CRLF i poświadczeń w enkoderach klienta SOCKS4 (Socks4ClientEncoder) i SOCKS5 (Socks5ClientEncoder), które nie walidują pól adresu domeny i uwierzytelniania (nazwa użytkownika/hasło). Atakujący kontrolujący te pola może wstrzyknąć bajty null lub znaki CRLF, aby skrócić lub zmienić wartości, co może prowadzić do fałszowania domen, skrócenia userid SOCKS4, wstrzyknięcia danych uwierzytelniających i zamieszania protokołu. Naprawiono w 4.2.17.Final i 4.1.137.Final.

Netty (io.netty:netty-handler) w wersjach od 4.2.0.Final do 4.2.16.Final oraz w wersjach do 4.1.136.Final wyłącza weryfikację nazwy hosta TLS na ścieżce klienta SslProvider.OPENSSL, gdy używany jest zwykły (nie rozszerzony) X509TrustManager i niedostępne jest opakowanie menedżera zaufania oparte na Unsafe (Java 25+). W tej konfiguracji klient OpenSSL nie przeprowadza weryfikacji nazwy hosta, co pozwala atakującemu typu man-in-the-middle na przedstawienie certyfikatu wydanego dla innej nazwy hosta, który jest akceptowany bez weryfikacji. Poprawiono w wersjach 4.2.17.Final i 4.1.137.Final.

W Netty przed wersjami 4.1.137.Final i 4.2.17.Final domyślne konstruktory SniHandler używają ścieżki agregacji ClientHello przed uzgadnianiem, gdzie handshakeBuffer.clear() i writeBytes() kopiują wszystkie wcześniej odebrane bajty dla każdego dodatkowego rekordu TLS. Nieuwierzytelniony zdalny peer może wysłać duży ClientHello w tysiącach małych rekordów, powodując kwadratowy wzrost obciążenia CPU w pętli zdarzeń przed zakończeniem uzgadniania TLS, co pogarsza obsługę TLS dla innych klientów.

Netty przed wersjami 4.1.137.Final i 4.2.17.Final ma podatność w CorsHandler setVaryHeader, która zastępuje nagłówki Vary aplikacji, takie jak Authorization lub Cookie, nagłówkiem Origin, co pozwala buforującemu proxy lub CDN na ponowne użycie uwierzytelnionych odpowiedzi między użytkownikami i ujawnienie wrażliwych informacji.

Netty przed wersjami 4.1.137.Final i 4.2.17.Final ma ograniczenia liczby niekompletnych wiadomości i fragmentów SCTP, ale nie limituje maxBufferedBytes, co pozwala nieuwierzytelnionym peerom na wyczerpanie pamięci dużymi fragmentami SCTP. Problem został naprawiony w wersjach 4.1.137.Final i 4.2.17.Final.