CVE-2021-21295
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Bardzo wysokie ryzykoPercentyl 97 - wyżej niż 97% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko dotyczy organizacji używających Netty jako proxy, gdzie żądania HTTP/2 są downgrade'owane do HTTP/1.1 i przekazywane dalej. Atakujący może przemycić żądania, co może prowadzić do zatrucia pamięci podręcznej, ominięcia kontroli dostępu lub innych ataków na backend.
Rekomendacja
Zaleca się natychmiastową aktualizację Netty do wersji 4.1.60.Final lub nowszej. Jeśli aktualizacja nie jest możliwa, należy zaimplementować własny `ChannelInboundHandler` w `ChannelPipeline` za `Http2StreamFrameToHttpObjectCodec`, aby ręcznie walidować nagłówek Content-Length.
Inne podatności w Netty
Zobacz wszystkie- CVE-2026-42583Wysokie
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ę.
- 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-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 an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS