CVE-2026-78659

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.

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

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