Wprowadzenie do problemu / definicja
Projekt curl opublikował poprawkę dla podatności związanej z obsługą uploadów przez HTTP/2, która może prowadzić do uszkodzenia pamięci po stronie klienta. Problem dotyczy zarówno narzędzia curl uruchamianego z wiersza poleceń, jak i biblioteki libcurl, wykorzystywanej przez wiele aplikacji i usług do realizacji transferów sieciowych.
Luka została oznaczona jako CVE-2026-92392. W określonych warunkach złośliwy serwer może doprowadzić do błędu typu use-after-free, czyli użycia pamięci po jej zwolnieniu. Tego typu podatności są szczególnie niebezpieczne, ponieważ mogą skutkować nie tylko awarią procesu, ale w sprzyjających warunkach również wykonaniem kodu.
W skrócie
- Podatność obejmuje wersje curl i libcurl od 8.12.0 do 8.22.0.
- Problem został naprawiony w wydaniu 8.23.0 oraz w wybranych poprawionych starszych gałęziach.
- Atak wymaga wysyłania danych do kontrolowanego przez napastnika serwera przez HTTPS z negocjacją HTTP/2.
- Warunkiem powodzenia jest także akceptacja certyfikatu serwera przez klienta.
- Najbardziej prawdopodobnym skutkiem pozostaje awaria aplikacji, ale badacze pokazali również scenariusz prowadzący do wykonania kodu.
Kontekst / historia
Problem został zgłoszony do projektu curl we wrześniu 2026 roku w ramach procesu obsługi zgłoszeń bezpieczeństwa. Po potwierdzeniu błędu zespół skrócił cykl wydawniczy, aby szybciej udostępnić poprawkę i ograniczyć ryzyko dla użytkowników.
Podatny kod był obecny we wszystkich wydaniach od lutego 2025 roku, kiedy pojawił się curl 8.12.0. Według dostępnych informacji nie odnotowano aktywnego wykorzystania luki w rzeczywistych kampaniach, jednak znaczenie sprawy wzrosło po publikacji materiałów pokazujących możliwość przejścia od korupcji pamięci do wykonania kodu po stronie klienta.
To również jedna z poważniejszych podatności w ekosystemie curl w ostatnim czasie. Ze względu na bardzo szerokie wykorzystanie libcurl w produktach open source, aplikacjach biznesowych, narzędziach serwerowych i automatyzacji, realna powierzchnia narażenia może być znacznie większa niż tylko liczba bezpośrednich instalacji pakietu curl.
Analiza techniczna
Źródłem problemu jest błąd w zarządzaniu cyklem życia obiektu reprezentującego transfer podczas uploadu realizowanego przez HTTP/2. W tym modelu wiele strumieni współdzieli jedno połączenie, a libcurl śledzi poszczególne operacje z użyciem struktur powiązanych z tak zwanym easy handle.
Scenariusz ataku zakłada aktywne sterowanie zachowaniem serwera odbierającego dane. Serwer może zatrzymać przesyłanie przez ustawienie okna HTTP/2 na zero, odesłać fragment odpowiedzi, a następnie zresetować strumień bez zamykania całego połączenia. Po stronie klienta taka sekwencja może zostać potraktowana jako przesłanka do ponowienia operacji.
Kluczowy problem pojawiał się w kolejności porządkowania zasobów. W podatnej logice warstwa HTTP/2 najpierw traciła powiązanie z uchwytem transferu, a dopiero później dochodziło do opróżniania pozostałych danych uploadu do tego samego połączenia. W rezultacie resztkowe dane mogły zostać potraktowane jak nowy request wysyłany przez istniejące połączenie.
To prowadziło do pozostawienia wskaźnika do struktury, która mogła zostać już zwolniona lub być w trakcie zwalniania. Jeżeli aplikacja kończyła operację i usuwała uchwyt, a starsze połączenie nadal przechowywało nieaktualne odwołanie, kolejne ramki HTTP/2 przesłane przez serwer mogły wywołać klasyczny stan use-after-free. W badawczym scenariuszu pokazano, że taki stan może zostać wykorzystany do nadpisania danych w pamięci i przejęcia sterowania wykonaniem.
Jednocześnie praktyczne wykorzystanie błędu nie jest trywialne. Wymaga bardzo precyzyjnej wiedzy o środowisku ofiary, w tym o konkretnej wersji curl, architekturze systemu, zachowaniu alokatora pamięci, układzie sterty oraz synchronizacji współbieżnych transferów. Z tego powodu autorzy projektu oceniają, że w praktyce częściej należy spodziewać się awarii procesu niż stabilnego i powtarzalnego zdalnego wykonania kodu.
Poprawka sama w sobie jest niewielka, ale istotna logicznie. Zmieniono kolejność operacji tak, aby referencje warstwy HTTP/2 do uchwytu transferu były zwalniane dopiero po opróżnieniu pozostałych danych uploadu. Dzięki temu usunięto okno prowadzące do użycia nieaktualnego wskaźnika.
Konsekwencje / ryzyko
Największe ryzyko dotyczy środowisk, w których aplikacje automatycznie przesyłają dane lub pliki do zewnętrznych serwerów przez HTTPS i korzystają z libcurl z aktywną obsługą HTTP/2. W tym przypadku zagrożenie nie wynika z pobierania treści, lecz z samego faktu wysyłania danych do serwera kontrolowanego przez przeciwnika.
Wpływ na organizację może obejmować zakłócenie działania procesów, utratę stabilności usług oraz potencjalną możliwość uruchomienia kodu w kontekście procesu klienckiego. Problem może mieć także charakter łańcuchowy, ponieważ wiele aplikacji używa libcurl pośrednio jako zależności, bez pełnej widoczności tego faktu po stronie administratorów.
- awarie procesów korzystających z libcurl,
- potencjalne wykonanie kodu w kontekście procesu klienta,
- ryzyko rozszerzenia skutków przy dobrze przygotowanym środowisku exploitacji,
- trudności w pełnej identyfikacji wszystkich podatnych komponentów zależnych od libcurl.
Szczególnie narażone mogą być systemy automatyzacji, narzędzia backupowe, agenci synchronizacji, integracje CI/CD oraz aplikacje serwerowe wysyłające dane do usług zewnętrznych. Jeżeli komponent negocjuje HTTP/2 domyślnie, powierzchnia ataku rośnie bez potrzeby stosowania nietypowej konfiguracji.
Rekomendacje
Podstawowym działaniem naprawczym jest aktualizacja do curl 8.23.0 albo do poprawionych wersji utrzymywanych starszych gałęzi. Organizacje powinny pamiętać, że problem nie ogranicza się do samej binarki curl, lecz obejmuje również aplikacje linkowane z podatną wersją libcurl.
- przeprowadzić inwentaryzację systemów i aplikacji wykorzystujących libcurl,
- zidentyfikować procesy realizujące upload przez HTTPS,
- sprawdzić, czy w używanych buildach obecna jest obsługa HTTP/2,
- zaktualizować pakiety systemowe, obrazy kontenerowe i zależności aplikacyjne,
- przetestować zgodność transferów po wdrożeniu poprawek.
Jeżeli natychmiastowa aktualizacja nie jest możliwa, rozsądnym środkiem tymczasowym pozostaje wymuszenie użycia HTTP/1.1 zamiast HTTP/2. Takie ograniczenie zmniejsza ryzyko wejścia na podatną ścieżkę wykonania. W środowiskach podwyższonego ryzyka warto też ograniczyć połączenia wychodzące do niezweryfikowanych endpointów uploadowych oraz monitorować awarie i nietypowe błędy transferu podczas wysyłania większych plików.
Zespoły bezpieczeństwa powinny dodatkowo uwzględnić ten przypadek w procesach zarządzania podatnościami zależności open source. Ze względu na wszechobecność libcurl pełny zakres ekspozycji może być większy, niż wynikałoby to z listy bezpośrednio instalowanych pakietów.
Podsumowanie
CVE-2026-92392 to istotna podatność w curl i libcurl związana z obsługą uploadów HTTP/2, prowadząca do use-after-free po stronie klienta. Chociaż skuteczne wykonanie kodu wymaga bardzo precyzyjnych warunków, sama możliwość uszkodzenia pamięci w tak szeroko stosowanej bibliotece uzasadnia szybkie działania naprawcze.
Dla większości organizacji priorytetem powinna być aktualizacja do bezpiecznej wersji oraz weryfikacja, które procesy przesyłają dane z użyciem libcurl i HTTP/2. Do czasu wdrożenia poprawek warto rozważyć wyłączenie HTTP/2 dla transferów wychodzących i zwiększone monitorowanie stabilności aplikacji.