CVE-2026-94439

Parsowanie formularza multipart może obejść limity pamięci i wczytać dowolnie długą linię do pamięci, gdy pozostały limit na początku części jest mniejszy niż 400 bajtów.

Złośliwy peer HTTP/2 może spowodować nadmierne zużycie CPU po stronie klienta lub serwera, otwierając dużą liczbę strumieni, a następnie wysyłając wiele małych ramek SETTINGS zawierających wartości SETTINGS_INITIAL_WINDOW_SIZE.

Podczas parsowania nagłówka Range zawierającego dużą liczbę małych zakresów, FileServer(FS), ServeContent i ServeFile(FS) mogą zużyć nadmierną ilość CPU.

Serwer HTTP/2 może dwukrotnie zwrócić kontrolę przepływu na poziomie połączenia dla tych samych danych: raz, gdy klient resetuje strumień, a ponownie, gdy handler żądania odczytuje buforowane dane. Złośliwy klient może to wykorzystać do obejścia skonfigurowanego limitu kontroli przepływu na poziomie połączenia (MaxReceiveBufferPerConnection).

Historycznie implementacja HTTP/2 była dość pobłażliwa wobec nieprawidłowych nagłówków związanych z ramkowaniem, ponieważ nie mogą one zakłócać ramkowania HTTP/2. Jednak umożliwia to przekazywanie odpowiedzi zawierających takie nagłówki do klienta HTTP/1, gdy działamy jako reverse proxy. Jeśli klient HTTP/1 również nie zachowuje się wystarczająco ściśle, może to skutkować przemytem odpowiedzi (response smuggling).

Gdy klient wysyła nagłówki "Trailer", serwer HTTP wewnętrznie używa wartości nagłówków do wypełnienia mapy Request.Trailer przekazywanej do handlera. Ponieważ Request.Trailer jest mapą, każdy wpis powoduje narzut pamięci. Dla serwerów HTTP/2 złośliwy klient może to wykorzystać, wysyłając nagłówek "Trailer" deklarujący dużą liczbę pól, powodując alokację nieproporcjonalnej ilości pamięci z pominięciem limitów Server.MaxHeaderValueCount i Server.MaxHeaderBytes.

Gdy http.Transport wysyła żądanie HTTP/1 CONNECT z niepustym Request.Body, zapisuje ciało bezpośrednio do połączenia bez ramkowania po nagłówkach żądania. Jeśli serwer odrzuci żądanie CONNECT odpowiedzią keep-alive inną niż 2xx, Transport zwraca połączenie do puli bezczynnych. Ponieważ żądania CONNECT nie mają ciała żądania, serwer może zinterpretować końcowe bajty ciała jako kolejne potokowe żądanie HTTP/1.1 na tym połączeniu, pozostawiając połączenie w puli zdesynchronizowane i powodując, że następny wywołujący, który je ponownie użyje, odczyta odpowiedź na wstrzyknięte żądanie.

Podatność w bibliotece net/http języka Go pozwala atakującemu HTTP na użycie rozszerzeń chunk do zmuszenia odbiorcy do odczytania znacznie większej ilości danych z sieci niż faktycznie znajduje się w treści żądania lub odpowiedzi. Złośliwy klient HTTP może wykorzystać to do automatycznego odczytania przez serwer dużej ilości danych (do około 1 GiB).

Podatność w standardowej bibliotece Go (net/http) powoduje, że przy przekierowaniu HTTP do domeny, która nie jest subdomeną ani dokładnym dopasowaniem początkowej domeny, klient HTTP nie przekazuje wrażliwych nagłówków, takich jak Authorization czy Cookie. Na przykład przekierowanie z foo.com na www.foo.com przekaże nagłówek Authorization, ale przekierowanie na inną domenę już nie.