CVE-2026-100663
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 21 - wyżej niż 21% wszystkich znanych CVE
Streszczenie
Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.2.Final do 4.2.17.Final nie obsługuje specjalnie metody CONNECT z formą authority-form, co prowadzi do tworzenia wadliwych żądań CONNECT w HTTP/3 z autorytetem kontrolowanym przez atakującego.
Ocena ryzyka
Możliwość obejścia list dozwolonych dla tuneli, polityki egress, wyboru backendu lub kontroli audytowych.
Rekomendacja
Zaktualizuj Netty do wersji 4.2.18.Final lub nowszej.
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's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets when converting HTTP/1 messages to HTTP/3 in HttpConversionUtil.toHttp3Headers. The authority-form target (e.g., "CONNECT trusted.example:443") is parsed as a URI, so its host is emitted as :scheme, :path is set to "/", and the HTTP/1 Host header is used as :authority; if no Host header is present the CONNECT target is dropped. In a Netty-based HTTP/1-to-HTTP/3 proxy or gateway, a remote client can send a CONNECT request whose Host header names a different authority than the request-target, producing a malformed HTTP/3 CONNECT whose tunnel :authority is attacker-controlled. This can bypass tunnel allow-lists, egress policy, backend selection, or audit controls that validate the HTTP/1 CONNECT request-target before forwarding over HTTP/3. The issue is fixed in 4.2.18.Final.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

