Netty może podczas konwersji HTTP/2 lub HTTP/3 Extended CONNECT do obiektu HTTP/1.1 CONNECT zgubić informacje o protokole/ścieżce, których wyższa warstwa potrzebuje do decyzji autoryzacyjnej. Efekt: gateway widzi zwykły CONNECT i podejmuje decyzję na niepełnych danych. To finding o semantic loss across protocol translation — biblioteka nie decyduje o autoryzacji, ale przez utratę danych może złamać security boundary.
netty-codec-http2/http3 nie wystarcza — liczy się, czy aplikacja przyjmuje Extended CONNECT i opiera politykę na utraconych polach.Attack path
SCA vs runtime
Obecność netty-codec-http2/netty-codec-http3 nie przesądza affectedness. Trzeba ustalić, czy aplikacja faktycznie przyjmuje Extended CONNECT, korzysta z podatnej konwersji i opiera decyzje autoryzacyjne na polach, które konwersja gubi. Inaczej finding jest albo zawyżony (pakiet obecny, ścieżka nieużywana), albo zaniżony (shaded kopia niewidoczna dla prostego SCA).
Verification
Po update potwierdź runtime dependency, faktycznie załadowany JAR, zachowanie metadanych po translacji i egzekwowanie polityki. Sprawdź shaded/embedded kopie Netty — biblioteka bywa wpakowana w inne artefakty i wtedy nie widać jej w bezpośrednim drzewie zależności.
Powiązane na blogu
- Netty CVE-2026-93572 — drugi finding z tego samego okna
- Traefik: cztery granice zaufania — proxy i utrata kontekstu
Źródła
- Red Hat — CVE-2026-93568 — access.redhat.com
- Netty GHSA-w6j8-x45j-w75f — github.com
Nota redakcyjna: stan informacji 27 września 2026. CVE-2026-93568 (Netty, utrata kontekstu przy translacji Extended CONNECT). Artykuł podkreśla różnicę między obecnością pakietu (SCA) a faktycznym użyciem podatnej ścieżki w runtime.