Podatności Go net/http

Dopasowywanie hostów do wzorców proxy może nieprawidłowo traktować identyfikator strefy IPv6 jako część nazwy hosta. Na przykład gdy zmienna NO_PROXY ma wartość "*.example.com", żądanie do "[::1%25.example.com]:80" zostanie błędnie dopasowane i nie zostanie przekierowane przez proxy.

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.

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).

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.

Gdy handler serwera HTTP wysyła odpowiedź 2xx na żądanie HTTP/1 CONNECT i zwraca bez przejęcia połączenia, serwer nieprawidłowo kontynuuje odczytywanie i obsługę żądań z tego połączenia. Ponieważ odpowiedź 2xx na CONNECT przekształca połączenie w tunel, serwer nie powinien traktować go jako nadal zawierającego HTTP.

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.

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.

Hosty wymienione w TrustedOrigins domyślnie zezwalają na żądania z odpowiadających im originów HTTP, co pozwala atakującym w sieci (MitM) na przeprowadzanie ataków CSRF. Po naprawie CVE-2025-24358 atakujący sieciowy, który umieści formularz na http://example.com, nie może go wysłać do https://example.com, ponieważ nagłówek Origin jest sprawdzany względem syntetycznego URL. Jednak jeśli host zostanie dodany do TrustedOrigins, dozwolone będą zarówno jego originy HTTP, jak i HTTPS, ponieważ schemat syntetycznego URL jest ignorowany, a sprawdzany jest tylko host.