CVE-2026-102560

W bibliotece libsoup podczas obsługi przychodzącej ramki WebSocket Pong, SoupWebsocketConnection emitował sygnał ::pong ze wskaźnikiem GByteArray, mimo że sygnał jest zadeklarowany do przekazywania GBytes. Aplikacje podłączające handler zgodny z udokumentowanym API GBytes mogą wywołać uszkodzenie sterty lub awarię po otrzymaniu spreparowanego Ponga.

W bibliotece libsoup odkryto podatność typu use-after-free w funkcji soup_message_headers_get_content_disposition(). Umożliwia ona złośliwemu klientowi HTTP wywołanie uszkodzenia pamięci w serwerze libsoup.

W SoupServer (libsoup) wykryto lukę. Gdy klient HTTP/1.x wysyła żądanie z nagłówkiem Expect: 100-continue i ciałem żądania, a SoupServer zwraca wczesną finalną odpowiedź (nie-1xx) przed odczytaniem ciała, serwer nie opróżnia zadeklarowanych bajtów ciała ani nie zamyka połączenia. W połączeniu keep-alive pozostałe bajty są interpretowane jako kolejne żądanie HTTP.

W bibliotece libsoup, podczas konstruowania maskowanej ramki WebSocket klienta dla bardzo dużego ładunku wychodzącego, wartości rozmiaru przekazywane do funkcji alokacji GByteArray mogą zostać obcięte, podczas gdy procedura maskowania nadal używa pełnej długości, co powoduje przepełnienie bufora sterty.

W bibliotece libsoup, gdy maksymalny rozmiar przychodzącego ładunku jest nieograniczony (0), SoupWebsocketConnection może zwiększać swój przychodzący GByteArray na podstawie długości ramki kontrolowanej przez atakującego, aż długość się zawinie, co powoduje przepełnienie bufora sterty podczas odczytu danych ramki.

W bibliotece libsoup funkcja soup_uri_decode_data_uri() nieprawidłowo traktowała ładunki data-URI base64 jako ciągi zakończone NUL podczas wywoływania g_base64_decode_inplace(). Jeśli ładunek po zdekodowaniu procentowo zawierał wbudowane bajty NUL, zdekodowana długość mogła pozostać niezainicjalizowana i być użyta jako rozmiar zwracanego GBytes. Może to prowadzić do odczytu poza zakresem lub awarii aplikacji podczas przetwarzania spreparowanego data URI.

W bibliotece libsoup podczas składania fragmentowanych wiadomości WebSocket do GByteArray nie ograniczano odpowiednio całkowitego rozmiaru wiadomości w stosunku do limitów bazowego typu bufora. Zdalny peer mógł wysyłać fragmenty powodujące obcięcie rozmiaru, podczas gdy implementacja nadal używała pełnej długości, co prowadziło do uszkodzenia sterty lub awarii.

W bibliotece libsoup wykryto podatność związaną z brakiem kontroli granic podczas przesyłania treści żądania HTTP/2 z nieodpytywalnego strumienia wejściowego. Złośliwy serwer HTTP/2 może zmniejszyć rozmiar okna przepływu (SETTINGS_INITIAL_WINDOW_SIZE) podczas trwającego buforowanego odczytu, co prowadzi do skopiowania pełnego bufora do mniejszego wywołania zwrotnego DATA bez kontroli granic, co może przerwać działanie procesu lub spowodować niepowodzenie sesji HTTP/2.

W bibliotece libsoup wykryto podatność use-after-free w implementacji klienta HTTP/2. Złośliwy serwer HTTP/2 lub atakujący typu man-in-the-middle może wykorzystać tę podatność, gdy aplikacja GNOME wysyła plik przez HTTP/2, a serwer wysyła ramkę GOAWAY podczas asynchronicznego odczytu treści pliku. Może to prowadzić do uszkodzenia pamięci, wycieku informacji lub wykonania dowolnego kodu.

W bibliotece libsoup występuje podatność na atak typu „odmowa usługi” (CPU exhaustion) związana z przetwarzaniem nagłówka HTTP Range. Mimo poprawki CVE-2025-32907, scalanie wielu identycznych zakresów w pętli wykonuje operacje O(N²), co przy maksymalnym rozmiarze nagłówka (~100 KiB) pozwala na zablokowanie pętli zdarzeń serwera na około 90 ms na żądanie. Podatność jest osiągalna po stronie serwera bez uwierzytelniania.