Krytyczna luka w Apache HTTP Server: CVE-2026-119618 grozi zdalnym wykonaniem kodu przez HTTP/2

Wprowadzenie do problemu / definicja

Apache HTTP Server pozostaje jednym z najczęściej wykorzystywanych serwerów WWW w środowiskach produkcyjnych, centrach danych i infrastrukturze chmurowej. Z tego powodu każda krytyczna podatność w tym oprogramowaniu może mieć bezpośredni wpływ na bezpieczeństwo publicznie dostępnych usług oraz systemów wewnętrznych.

Najnowszy problem, oznaczony jako CVE-2026-119618, dotyczy modułu mod_http2. Luka może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia, jeśli na serwerze aktywowano obsługę protokołu HTTP/2. To czyni ją szczególnie groźną dla organizacji, które udostępniają aplikacje internetowe na bazie Apache i korzystają z nowoczesnych mechanizmów komunikacji sieciowej.

W skrócie

Podatność została usunięta w Apache HTTP Server 2.4.71, opublikowanym 11 listopada 2026 roku. Problem obejmuje wersje od 2.4.55 do 2.4.70 oraz samodzielne wydania mod_h2 od 2.0.8 do 2.0.42.

Luka dotyczy modułu mod_http2.
Możliwy jest atak zdalny bez logowania i bez interakcji użytkownika.
Zagrożone są wyłącznie instancje z aktywnym h2 lub h2c.
Serwery obsługujące wyłącznie HTTP/1.1 nie są podatne.
Błąd może prowadzić do uszkodzenia pamięci sterty i w konsekwencji do RCE.
W razie braku możliwości natychmiastowej aktualizacji zalecane jest czasowe wyłączenie HTTP/2.

Kontekst / historia

Poprawka dla CVE-2026-119618 została udostępniona w ramach listopadowego zestawu aktualizacji bezpieczeństwa Apache. Oficjalne advisory wskazało, że problem ma charakter krytyczny i obejmuje szeroki zakres wersji z linii 2.4.x, co zwiększa jego znaczenie operacyjne dla organizacji utrzymujących rozproszone środowiska serwerowe.

Podatność została zgłoszona pod koniec października 2026 roku przez Anthropic OSS Scanner, a następnie również przez badaczy Google Cloud Vulnerability Research. To pokazuje, że problem został zauważony niezależnie przez więcej niż jeden podmiot, co zwykle wzmacnia ocenę jego istotności.

Dodatkowego znaczenia sprawie nadaje fakt, że w 2026 roku warstwa odpowiedzialna za HTTP/2 w Apache była już wcześniej przedmiotem analiz bezpieczeństwa. Oznacza to, że organizacje powinny traktować mod_http2 jako komponent wymagający szczególnie uważnego zarządzania poprawkami i konfiguracją.

Analiza techniczna

Źródłem podatności jest błąd synchronizacji w funkcji assign_headers() w module mod_http2. Problem został opisany jako niewłaściwa synchronizacja współdzielonych zasobów podczas współbieżnego wykonania, co w praktyce oznacza ryzyko niekontrolowanego dostępu do pamięci w warunkach wielowątkowej obsługi żądań HTTP/2.

W scenariuszu ataku może dojść do zapisu do pamięci należącej do innego kontekstu wykonania przy wykorzystaniu współdzielonego alokatora. Taki stan może skutkować uszkodzeniem sterty, a następnie przejęciem przepływu wykonania procesu serwera. Z perspektywy obrońcy kluczowe jest to, że atak nie wymaga lokalnego dostępu ani wcześniejszej kompromitacji konta.

Zakres ryzyka zależy od konfiguracji. Podatne są systemy, w których dyrektywa Protocols włącza h2 lub h2c. Ustawienia te mogą być zdefiniowane zarówno globalnie, jak i na poziomie poszczególnych virtual hostów, dlatego analiza ekspozycji powinna objąć cały zestaw konfiguracji serwera, w tym reverse proxy, gotowe szablony wdrożeniowe i obrazy kontenerowe.

Warto również uwzględnić różnice pomiędzy dystrybucjami. Część dostawców systemów może stosować własne poprawki lub backporty, a niektóre implementacje utrudniają skuteczną eksploatację błędu. Nie zmienia to jednak podstawowego faktu: luka istnieje i powinna zostać usunięta przez aktualizację do poprawionej wersji lub pakietu dostawcy.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem CVE-2026-119618 jest możliwość zdalnego wykonania kodu w kontekście procesu serwera WWW. W praktyce może to oznaczać przejęcie usługi frontowej, manipulację ruchem HTTP, instalację webshella, kradzież danych aplikacyjnych oraz próbę dalszego ruchu bocznego do systemów zaplecza.

Ryzyko jest wysokie także dlatego, że luka łączy kilka niebezpiecznych cech: atak sieciowy, brak wymogu uwierzytelnienia, niski próg wejścia oraz potencjalny wpływ na poufność, integralność i dostępność. W środowiskach chmurowych skuteczna kompromitacja może dodatkowo zwiększyć zagrożenie dla sekretów aplikacyjnych, usług sąsiednich lub mechanizmów orkiestracji.

Problem może pozostać niezauważony w organizacjach, które nie są świadome, że HTTP/2 zostało aktywowane pośrednio przez domyślne ustawienia dystrybucji, gotowe obrazy systemowe albo konfiguracje wdrożone przez zespoły DevOps. Dlatego sama inwentaryzacja wersji Apache nie wystarczy bez jednoczesnej weryfikacji aktywnych protokołów.

Rekomendacje

Priorytetem powinno być szybkie zidentyfikowanie wszystkich instancji Apache HTTP Server w wersjach od 2.4.55 do 2.4.70 oraz wdrożeń mod_h2 od 2.0.8 do 2.0.42. Następnie należy przeprowadzić aktualizację do Apache HTTP Server 2.4.71 lub zainstalować poprawione pakiety dostarczone przez producenta systemu operacyjnego.

Jeżeli natychmiastowa aktualizacja nie jest możliwa, rozsądnym działaniem tymczasowym jest wyłączenie HTTP/2 poprzez usunięcie h2 i h2c z dyrektywy Protocols i pozostawienie wyłącznie HTTP/1.1. Takie obejście ogranicza powierzchnię ataku, choć może wpłynąć na wydajność i zachowanie części klientów.

Przeprowadzić pełny przegląd konfiguracji Apache, w tym wszystkich virtual hostów.
Zweryfikować, gdzie HTTP/2 jest aktywne globalnie i lokalnie.
Sprawdzić obrazy kontenerowe, golden images oraz szablony IaC.
Monitorować logi pod kątem awarii procesów, anomalii i nietypowych restartów.
Wzmocnić ochronę dodatkowymi kontrolami, takimi jak EDR, WAF i segmentacja sieciowa.
Przygotować procedurę szybkiego przełączenia usług na konfigurację HTTP/1.1.
Ocenić stan pakietów na podstawie advisory producenta systemu, a nie wyłącznie numeru wersji wykrytego przez skaner.

Podsumowanie

CVE-2026-119618 to jedna z najpoważniejszych podatności Apache HTTP Server ujawnionych w 2026 roku. Luka w mod_http2 może zostać wykorzystana zdalnie bez uwierzytelnienia i prowadzić do wykonania kodu po stronie serwera, co stwarza realne ryzyko przejęcia usług internetowych.

Organizacje korzystające z Apache powinny potraktować tę sprawę priorytetowo. Kluczowe działania to identyfikacja wszystkich podatnych instancji, wdrożenie poprawek oraz czasowe wyłączenie HTTP/2 tam, gdzie aktualizacja nie może zostać przeprowadzona natychmiast.