Apache HTTP Server usuwa krytyczną lukę RCE w HTTP/2. Zagrożone wersje 2.4.55–2.4.70

Wprowadzenie do problemu / definicja

Apache HTTP Server załatał krytyczną podatność oznaczoną jako CVE-2026-119618, która dotyczy modułu mod_http2 i może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia. Problem wynika z błędnej synchronizacji współdzielonych zasobów podczas równoległego przetwarzania żądań, co może skutkować uszkodzeniem pamięci sterty i przejęciem kontroli nad procesem serwera WWW.

Luka ma szczególne znaczenie dla organizacji korzystających z HTTP/2, ponieważ warunkiem skutecznej eksploatacji jest aktywna obsługa tego protokołu. W praktyce oznacza to, że sama obecność podatnej wersji Apache nie zawsze oznacza pełną ekspozycję, ale każdy system z włączonym mod_http2 powinien zostać potraktowany priorytetowo.

W skrócie

CVE-2026-119618 to krytyczna podatność RCE w module mod_http2.
Wpływa na Apache HTTP Server w wersjach od 2.4.55 do 2.4.70.
Dotyczy także samodzielnego modułu mod_h2 w wersjach od 2.0.8 do 2.0.42.
Poprawka została udostępniona w Apache HTTP Server 2.4.71.
Eksploatacja wymaga aktywnego HTTP/2, czyli obsługi h2 lub h2c.
Atak nie wymaga wcześniejszego uwierzytelnienia.

Kontekst / historia

Podatność została wykryta niezależnie przez zespoły badawcze Anthropic OSS Scanner oraz Google Cloud Vulnerability Research. Poprawki opublikowano 11 listopada 2026 roku wraz z wydaniem Apache HTTP Server 2.4.71, co nadało sprawie wysoki priorytet w środowiskach utrzymujących publicznie dostępne usługi webowe.

W tym samym cyklu aktualizacji Apache usunął także inne błędy bezpieczeństwa, w tym luki związane z modułami mod_md oraz mod_vhost_alias. To pokazuje, że aktualizacja do najnowszego wydania nie powinna być traktowana wyłącznie jako reakcja na pojedyncze CVE, ale jako element szerszego procesu ograniczania ryzyka w warstwie serwera HTTP.

Dodatkowy niepokój budzi skala potencjalnej ekspozycji. W wielu środowiskach chmurowych i hybrydowych Apache pełni rolę reverse proxy, load balancera albo frontowego serwera aplikacyjnego, przez co ewentualne przejęcie procesu httpd może otworzyć drogę do dalszych etapów ataku.

Analiza techniczna

Źródłem problemu jest warunek wyścigu w funkcji assign_headers() w module mod_http2. Mechanizm obsługi współbieżnych żądań HTTP/2 dopuszcza sytuację, w której kilka wątków operuje na współdzielonych zasobach bez właściwej synchronizacji. Taki stan może prowadzić do uszkodzenia pamięci sterty, a następnie do wykonania kodu w kontekście procesu serwera.

Z punktu widzenia atakującego istotne są trzy cechy tej podatności. Po pierwsze, nie jest wymagane uwierzytelnienie. Po drugie, wektor ataku dotyczy warstwy protokołu HTTP/2, więc podatne są tylko te wdrożenia, w których aktywowano obsługę h2 lub h2c. Po trzecie, skuteczne wykonanie kodu odbywa się z uprawnieniami procesu serwera WWW, co może przełożyć się na dostęp do hostowanych aplikacji, danych sesyjnych, materiałów konfiguracyjnych lub sekretów aplikacyjnych.

Istotne jest także rozróżnienie między podatnością wersji a realną ekspozycją. Zgodnie z typową logiką konfiguracji Apache, domyślnie aktywny pozostaje HTTP/1.1, natomiast HTTP/2 musi zostać włączony jawnie. Oznacza to, że ocena ryzyka wymaga nie tylko sprawdzenia numeru wersji, ale także audytu dyrektyw protokołów na poziomie hosta i virtual hosta.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem skutecznej eksploatacji CVE-2026-119618 jest zdalne wykonanie kodu na serwerze frontowym. W środowiskach produkcyjnych może to oznaczać przejęcie aplikacji webowych, manipulację ruchem HTTP, kradzież danych, wdrożenie narzędzi post-exploitation lub wykorzystanie hosta jako punktu wejścia do dalszego ruchu bocznego.

Ryzyko rośnie szczególnie w następujących scenariuszach:

Apache działa jako publicznie dostępny reverse proxy lub load balancer.
Proces serwera ma nadmierne uprawnienia do systemu plików albo lokalnych zasobów.
Host współdzieli infrastrukturę z aplikacjami kontenerowymi, usługami wewnętrznymi lub zasobami chmurowymi.
Organizacja nie posiada pełnej inwentaryzacji instancji Apache oraz konfiguracji HTTP/2.
Serwer przetwarza ruch dla wielu aplikacji i domen, co zwiększa potencjalny wpływ incydentu.

Choć w chwili publikacji nie wskazywano publicznie dostępnego exploita ani potwierdzonych kampanii aktywnie wykorzystujących tę lukę, jej charakter techniczny i klasa zagrożenia sugerują, że okno bezpiecznej reakcji jest krótkie. W praktyce zespoły bezpieczeństwa powinny zakładać szybkie pojawienie się prób odtworzenia błędu i testów exploitacyjnych.

Rekomendacje

Podstawowym działaniem powinno być niezwłoczne przejście na Apache HTTP Server 2.4.71 lub nowszy. Organizacje korzystające z samodzielnie utrzymywanego modułu mod_h2 powinny równolegle zweryfikować jego wersję i stan wdrożenia poprawek.

Dodatkowe działania ograniczające ryzyko obejmują:

Zidentyfikowanie wszystkich instancji Apache w wersjach 2.4.55–2.4.70.
Sprawdzenie, czy w konfiguracji aktywowano HTTP/2 przez dyrektywy związane z Protocols, h2 lub h2c.
Tymczasowe wyłączenie HTTP/2 i ograniczenie obsługi do HTTP/1.1, jeśli natychmiastowa aktualizacja nie jest możliwa.
Przegląd logów pod kątem nietypowych błędów procesów potomnych, restartów usług i oznak niestabilności pamięci.
Ograniczenie uprawnień procesu httpd zgodnie z zasadą najmniejszych uprawnień.
Segmentację sieciową oraz odseparowanie warstwy WWW od wrażliwych usług zaplecza.
Uwzględnienie tej luki w skanowaniu podatności, procedurach patch management i planach reagowania na incydenty.

Dla zespołów SOC i administratorów kluczowe jest skorelowanie informacji o wersji oprogramowania z rzeczywistą konfiguracją protokołów. Tylko wtedy można odróżnić systemy teoretycznie podatne od tych, które są faktycznie wystawione na atak.

Podsumowanie

CVE-2026-119618 to krytyczna podatność typu RCE w module mod_http2 Apache HTTP Server, wynikająca z błędu synchronizacji i prowadząca do uszkodzenia pamięci. Zagrożone są wersje 2.4.55–2.4.70, a poprawka została dostarczona w wydaniu 2.4.71.

Najważniejszym czynnikiem ryzyka pozostaje aktywne HTTP/2, dlatego organizacje powinny równocześnie aktualizować oprogramowanie i weryfikować konfigurację usług. To przypadek, w którym szybkie patchowanie oraz zmniejszenie powierzchni ataku mogą zadecydować o uniknięciu poważnego incydentu.