CVE-2026-45416
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 57 - wyżej niż 57% wszystkich znanych CVE
Streszczenie
W Netty przed wersjami 4.1.135.Final i 4.2.15.Final, w metodzie SslClientHelloHandler.decode() występuje podatność na nadmierną alokację pamięci. Gdy ClientHello nie mieści się w pierwszym rekordzie, handler alokuje bufor o rozmiarze handshakeLength, a domyślne konstruktory SniHandler/AbstractSniHandler wyłączają zabezpieczenia (maxClientHelloLength=0, handshakeTimeoutMillis=0). Żądanie o rozmiarze 16 MiB powoduje natychmiastową alokację dużego, niebuforowanego bloku pamięci, który jest przechowywany aż do zamknięcia kanału.
Ocena ryzyka
Atakujący może zdalnie spowodować wyczerpanie pamięci serwera (DoS) poprzez wysłanie spreparowanego żądania TLS ClientHello, co może doprowadzić do odmowy usługi.
Rekomendacja
Zaleca się natychmiastową aktualizację Netty do wersji 4.1.135.Final lub 4.2.15.Final, które zawierają poprawkę.
Inne podatności w Netty
Zobacz wszystkie- CVE-2026-42577Wysokie
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ń.
- CVE-2016-4970Wysokie
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ę.
- CVE-2026-75595Krytyczne
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.
- CVE-2026-56817Krytyczne
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).
- CVE-2021-21409Średnie
Netty (io.netty:netty-codec-http2) przed wersją 4.1.61.Final zawiera podatność umożliwiającą przemycanie żądań (request smuggling). Nagłówek content-length nie jest poprawnie walidowany, gdy żądanie używa pojedynczego Http2HeaderFrame z ustawionym endStream na true. Może to prowadzić do przemycania żądań, jeśli żądanie jest proxy do zdalnego peera i tłumaczone na HTTP/1.1. Jest to kontynuacja GHSA-wm47-8v5p-wjpj/CVE-2021-21295, która nie naprawiła tego przypadku. Naprawiono w wersji 4.1.61.Final.
- CVE-2021-21295Średnie
Netty (io.netty:netty-codec-http2) przed wersją 4.1.60.Final zawiera podatność umożliwiającą przemycanie żądań (request smuggling). Gdy żądanie HTTP/2 jest konwertowane do HTTP/1.1 przez `Http2StreamFrameToHttpObjectCodec` i przekazywane do zdalnego serwera, nagłówek Content-Length nie jest walidowany przez `Http2MultiplexHandler`, co pozwala atakującemu na osadzenie dodatkowych żądań w treści.
- CVE-2019-20445Krytyczne
HttpObjectDecoder.java w Netty przed wersją 4.1.44 pozwala na wystąpienie nagłówka Content-Length wraz z drugim nagłówkiem Content-Length lub nagłówkiem Transfer-Encoding, co może prowadzić do nieprawidłowego przetwarzania żądań HTTP.
- CVE-2019-20444Krytyczne
W pliku HttpObjectDecoder.java w bibliotece Netty przed wersją 4.1.44 nagłówek HTTP pozbawiony dwukropka może zostać zinterpretowany jako osobny nagłówek o nieprawidłowej składni lub jako "invalid fold". Może to prowadzić do błędnej interpretacji żądań HTTP.
- CVE-2019-16869Wysokie
Netty w wersjach przed 4.1.42.Final nieprawidłowo obsługuje białe znaki przed dwukropkiem w nagłówkach HTTP (np. w linii "Transfer-Encoding : chunked"). Prowadzi to do przemytu żądań HTTP (HTTP request smuggling).
- CVE-2026-100666Wysokie
Netty HttpServerCodec do wersji 4.2.17.Final i 4.1.137.Final niepoprawnie paruje odpowiedzi z żądaniami przy pipeliningu HTTP/1.1 z nagłówkiem Expect: 100-continue, co prowadzi do rozdzielania odpowiedzi i niebezpiecznego ponownego użycia połączenia.
Oryginalny opis (angielski, źródło NVD)
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

