CVE-2026-93574

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).

Wada w dekoderze HTTP/1 biblioteki Netty. Niepełna walidacja zniekształconych nagłówków Transfer-Encoding pozwala zdalnemu atakującemu na przemyt żądań HTTP. Poprzez wysyłanie specjalnie spreparowanych żądań HTTP atakujący może wstrzykiwać dowolne żądania HTTP.

W stosie HTTP/2 biblioteki Netty wykryto lukę, która pozwala zdalnemu atakującemu na wstrzyknięcie zabronionych znaków, takich jak NUL, Line Feed i Carriage Return, do wartości pól nagłówka HTTP/2 z powodu niewystarczającej walidacji. Gdy wartości te przekraczają granicę tłumaczenia HTTP/2 na HTTP/1.1, mogą być wykorzystane do przemytu żądań, wstrzykiwania nagłówków lub rozdzielania odpowiedzi.

Luka w Netty netty-codec-smtp polega na nieprawidłowej walidacji znaków CR i LF w polu nazwy komendy SMTP. Zdalny atakujący, jeśli aplikacja przekazuje niezaufane dane do tego pola, może wstrzyknąć dowolne komendy SMTP, prowadząc do przemytu komend SMTP.

W dekoderze HTTP/1.1 biblioteki Netty występuje luka pozwalająca zdalnemu atakującemu obejść walidację nagłówka Transfer-Encoding poprzez podzielenie go na wiele nagłówków, gdzie ostatni zawiera niekońcowe kodowanie transferu, takie jak gzip lub deflate. Obejście to może prowadzić do przemytu żądań HTTP.

Luka w Netty dotyczy procesu konwersji HTTP/1 na HTTP/2. Gdy żądanie HTTP/1 zawiera zarówno absolutny request-target, jak i sprzeczny nagłówek Host, Netty błędnie priorytetowo traktuje nagłówek Host dla pola :authority w HTTP/2, odrzucając oryginalny autorytet request-target.