CVE-2026-119618: Krytyczna luka w Apache HTTP/2 umożliwia zdalne wykonanie kodu

Apache wydało pilną aktualizację zabezpieczeń, adresującą CVE-2026-119618, krytyczną podatność umożliwiającą zdalne wykonanie kodu w module mod_http2 serwera Apache HTTP Server. Usterka dotyczy wersji Apache HTTP Server od 2.4.55 do 2.4.70 i może pozwolić zdalnemu atakującemu na uszkodzenie pamięci sterty i potencjalnie wykonanie dowolnych poleceń na podatnych serwerach.

Podatność wynika z niewłaściwej synchronizacji przy przetwarzaniu przez Apache równoczesnych żądań HTTP/2. Wiele wątków może uzyskać dostęp do wspólnych zasobów bez wystarczającej koordynacji, tworząc sytuację wyścigu, która pozwala jednemu wątkowi na modyfikowanie pamięci używanej przez inny. Udana eksploatacja może uszkodzić wewnętrzną stertę serwera, co ostatecznie prowadzi do zdalnego wykonania kodu.

Na znaną ścieżkę ataku wystawione są jedynie wdrożenia Apache z włączonym HTTP/2. Serwery skonfigurowane wyłącznie na HTTP/1.1 nie osiągają podatności mod_http2. HTTP/2 można włączyć używając h2 dla połączeń TLS lub h2c dla jawnutek tekstowych HTTP/2 poprzez dyrektywę Protocols Apache.

Skontaktuj się ze sprzedażą

Apache rozwiązało problem podatności w HTTP Server 2.4.71, wydanym 11 listopada 2026 roku. Samodzielne wydania mod_h2 z GitHub w wersjach 2.0.8 do 2.0.42 są również dotknięte. Oficjalne doradztwo Apache obecnie nie identyfikuje osobno wydanej stałej wersji mod_h2.

Red Hat przypisało podatności ogólną ocenę CVSS 3.1 wynoszącą 9.8, opartą na dostępności w sieci, niskiej złożoności eksploatacji, która nie wymaga ani uwierzytelnienia, ani interakcji użytkownika. Red Hat dodatkowo stwierdza, że badania wykazały niezawodną eksploatację przeciwko domyślnie skonfigurowanemu serwerowi z włączonym mod_http2.

Jednakże, na dzień 12 listopada 2026 roku ani Apache, ani przeglądane raporty bezpieczeństwa nie dokumentują eksploatacji w rzeczywistych atakach. Wiz również nie zgłosił znanej eksploatacji w przyrodzie na moment publikacji. Organizacje powinny jednak priorytetowo podchodzić do łatania, ponieważ podatność jest zdalnie osiągalna, a jej techniczna przyczyna jest już publiczna.

Organizacje mogą wzmacniać swoje obrony przed rodzącą się eksploatacją za pomocą AI-Native Detection Intelligence Platform SOC Prime, umożliwiającego zespołom bezpieczeństwa wdrożenie inteligencji zagrożeń i przyspieszenie inżynierii wykrywania i poszukiwania zagrożeń w środowiskach SIEM, EDR, XDR i Data Lake.

Wykryj CVE-2026-119618 przez zidentyfikowanie podatnych serwerów Apache wystawionych na sieć z włączonym HTTP/2 i skorelownie podejrzanej aktywności HTTP/2 z awariami Apache, nieprawidłowymi procesami potomnymi, niespodziewanym wykonaniem poleceń, nowo utworzonymi plikami i nietypowymi wychodzącymi połączeniami sieciowymi.

Treści wykrywania mogą nie być dostępne dla każdego CVE. Sprawdź aktualny zakres na platformie SOC Prime. Jeśli istotne detekcje nie są jeszcze dostępne, sprawdź ponownie, ponieważ nowa inteligencja zagrożeń i treści wykrywania są stale dodawane.

Analiza CVE-2026-119618

CVE-2026-119618 dotyka wersje Apache HTTP Server od 2.4.55 do 2.4.70, gdy jest obecna podatna funkcjonalność mod_http2 i włączony jest HTTP/2. Projekt samodzielny mod_h2 jest dotknięty od wersji 2.0.8 do 2.0.42. Apache klasyfikuje problem jako krytyczny i mapuje go do CWE-362, Równoczesne Wykonanie przy Użyciu Wspólnych Zasobów z Niewłaściwą Synchronizacją.

Podatność istnieje w funkcji assign_headers(), używanej przez procesy HTTP/2 Apache.

HTTP/2 różni się znacząco od HTTP/1.1, ponieważ wiele strumieni może działać jednocześnie w ramach jednego połączenia. Moduł mod_http2 Apache dlatego wykorzystuje kilka wątków do przetwarzania żądań i zarządzania strumieniami HTTP/2 jednocześnie.

Problem pojawia się, gdy te wątki wchodzą w interakcję z pamięcią współdzieloną bez wystarczającej synchronizacji. Według oceny technicznej Red Hat, pracownik strumienia HTTP/2 może zapisać do pamięci będącej własnością wątku połączenia za pośrednictwem współdzielonego, bezblokowego alokatora.

Pod kontrolowanym przez atakującego czasie, jednoczesny dostęp może uszkodzić stertę.

Podatności prowadzące do uszkodzenia sterty mogą mieć różne efekty w zależności od układu pamięci i kontroli atakującego. Nieudana eksploatacja może spowodować awarię procesów roboczych Apache, podczas gdy wystarczająco kontrolowane uszkodzenie może zmodyfikować stan programu lub przekierować wykonanie.

Red Hat stwierdza, że udana eksploatacja może pozwolić atakującemu bez uwierzytelnienia wykonać dowolne polecenia z uprawnieniami procesu serwera Apache HTTP. Może to dać atakującym dostęp do danych aplikacji, plików konfiguracyjnych, poświadczeń dostępnych dla serwera sieciowego oraz innych zasobów dostępnych w tym kontekście bezpieczeństwa.

Podatność jest szczególnie niepokojąca w systemach skierowanych na zewnątrz, ponieważ nie jest wymagane żadne ważne konto, hasło, klucz API ani inne uwierzytelnienie. Atakujący potrzebuje jedynie dostępu sieciowego do dotkniętego punktu końcowego HTTP/2.

Ekspozycja zależy jednak od konfiguracji.

Apache HTTP Server musi faktycznie oferować HTTP/2. Administratorzy mogą to włączyć za pomocą dyrektywy Protocols używając:

Protocols h2 http/1.1

dla HTTP/2 przez TLS, lub:

Protocols h2c http/1.1

gdzie obsługiwane jest jawnutekstowe HTTP/2.

Dyrektywę można skonfigurować globalnie lub na poszczególnych wirtualnych hostach, co oznacza, że administratorzy powinni sprawdzić zarówno konfiguracje serwerowe, jak i lokalne, oceniając narażenie.

Serwer korzystający z dotkniętej wersji Apache, ale obsługujący wyłącznie HTTP/1.1, nie jest podatny na tę usterkę. Red Hat szczególnie potwierdza, że systemy bez włączonego HTTP/2 nie osiągają dotkniętej ścieżki kodowej.

Zakres dotkniętych wersji upstream Apache nie powinien również być stosowany bez uzasadnienia do pakietów dystrybucji Linuxa.

Red Hat Enterprise Linux 8 i wcześniejsze wersje nie zawierają podatnego kodu i nie są dotknięte. RHEL 9 i RHEL 10 zawierają dotknięte pakiety mod_http2, ale Red Hat przydziela ten problem jako „ważny”, a nie „krytyczny” na tych platformach.

Różnica wynika z szczegółów implementacji. W RHEL 9 i 10 każdy strumień HTTP/2 otrzymuje osobny alokator pamięci zamiast współdzielić się tym samym alokatorem z połączeniem. Red Hat twierdzi, że ta architektura znacznie zwiększa złożoność eksploatacji, chociaż dotknięte systemy nadal wymagają aktualizacji zabezpieczeń.

Red Hat wydał poprawione pakiety dla wielu strumieni RHEL 9 i RHEL 10 11 listopada. Administratorzy korzystający z utrzymywanych przez dostawcę pakietów Linuxa powinni zainstalować aktualizację zabezpieczeń swojej dystrybucji zamiast określać podatność wyłącznie na podstawie wersji Apachea wyświetlanej przez serwer.

Apache HTTP Server 2.4.71 zapewnia poprawkę upstream. Poprawka modyfikuje podatne zachowanie synchronizacji i zarządzania pamięcią, tak aby równoczesne operacje HTTP/2 nie mogły współdziałać z dotkniętymi wspólnymi zasobami w niebezpieczny sposób.

Podatność została niezależnie odkryta w wyniku dwóch badań naukowych.

Skanner OSS Anthropic zgłosił problem do zespołu bezpieczeństwa Apache 26 października 2026 roku pod identyfikatorem ANT-2026-MAPKT6MZ. Anthony Weems i Simon Scannell z Google Cloud Vulnerability Research niezależnie zgłosili podatność 3 listopada. Apache wydała poprawkę 11 listopada.

Rekord CVE został opublikowany 11 listopada 2026 roku.

Sytuacja dotycząca PoC CVE-2026-119618 wymaga ostrożnej interpretacji. Red Hat stwierdza, że badania publiczne wykazały wiarygodny exploit przeciwko serwerowi skonfigurowanemu domyślnie z włączonym mod_http2. Jednak The Hacker News i Wiz zgłosiły, że nie zidentyfikowano żadnego publicznie dostępnego exploita RCE, gdy ich raporty były publikowane. Projekty wprowadzane na GitHub, twierdzące, że posiadają skanery lub narzędzia związane z eksploatacją, nie powinny więc być automatycznie uznawane za zweryfikowany uzbrojony kod RCE.

To rozróżnienie ma znaczenie operacyjne. Obrońcy powinni zakładać, że usterka jest technicznie eksploatowana, unikając twierdzeń o szeroko rozprzestrzenionym niezawodnym uzbrojonym exploicie, chyba że pojawią się dalsze dowody.

Dla wykrycia CVE-2026-119618 zespoły bezpieczeństwa powinny najpierw zidentyfikować systemy wystawione, zamiast polegać wyłącznie na sygnaturach exploitów.

Administratorzy mogą potwierdzić, czy moduł HTTP/2 jest załadowany używając:

apachectl -M | grep http2

Powinni następnie zbadać pliki konfiguracyjne Apachea dla dyrektyw Protocols zawierających h2 lub h2c, w tym dyrektywy zdefiniowane wewnątrz poszczególnych wirtualnych hostów.

Zewnętrzne wykrywanie usług może również zidentyfikować serwery negocjujące HTTP/2 przez TLS ALPN. Jednak samo identyfikowanie wersji może być mylące, ponieważ dystrybucje Linuxa często backportują poprawki podatności bez zmiany ciągu wersji wyglądającej na upstream.

Telemetria czasu wykonania powinna być skorelowana z podejrzanym ruchem HTTP/2. Potencjalne wskaźniki behawioralne obejmują powtarzające się awarie procesów roboczych Apache, uchybienia segmentacji, nieprawidłowe restarty, komunikaty o uszkodzeniu pamięci lub nagłe niestabilności serwisu związane z nietypowymi lawinowymi żądaniami HTTP/2.

Ponieważ udana eksploatacja może zapewnić wykonanie polecenia, telemetria punktu końcowego i gospodarza powinna być również przeglądana pod kątem nietypowych procesów potomnych pochodzących z Apache.

Przykłady obejmują nieoczekiwane uruchamianie powłok, interpreterów skryptów, narzędzi pobierających czy poleceń administracji systemu przez httpd lub apache2.

Zespoły bezpieczeństwa powinny badać relacje procesów takie jak:

httpd → /bin/sh

apache2 → bash

httpd → curl

apache2 → wget

lub inne łańcuchy wykonania niezgodne z normalnym zachowaniem aplikacji hostowanej.

Tworzenie plików w katalogach tymczasowych, rootach sieciowych, lokalizacjach startowych lub katalogach aplikacji do zapisu może również wskazywać na aktywność poeksploatacyjną. Niespodziewane połączenia wychodzące z procesów roboczych Apache także powinny być poddane kontroli.

Obecnie nie ma opublikowanych przez dostawców wskaźników kampanii specyficznych dla CVE-2026-119618, takich jak złośliwe adresy IP, domeny, hashe ładunków lub infrastruktura atakującego, ponieważ Apache i przeglądane źródła nie zgłosiły eksploatacji w przyrodzie. To sprawia, że ocena konfiguracji i monitoring oparty na zachowaniu są bardziej wartościowe niż dopasowywanie statycznych wskaźników.

Łagodzenie CVE-2026-119618

Głównym remedium jest aktualizacja dotkniętych instalacji Apache HTTP Server do wersji 2.4.71 lub zastosowanie poprawionej paczki zabezpieczeń dostarczonej przez dostawcę systemu operacyjnego. Apache 2.4.71 został wydany 11 listopada 2026 roku i zawiera poprawkę upstream.

Organizacje powinny priorytetowo podchodzić do wdrożeń Apache skierowanych na internet z włączonym HTTP/2, ponieważ te systemy bezpośrednio wystawiają podatną funkcjonalność na niezaufany ruch sieciowy.

Administratorzy powinni podjąć następujące kroki:

1. Sporządź inwentarz wdrożeń Apache HTTP Server w środowiskach produkcyjnych, deweloperskich, chmurowych i kontenerowych.
2. Zidentyfikuj instalacje działające na Apache 2.4.55 do 2.4.70.
3. Zweryfikuj, czy mod_http2 jest załadowany.
4. Sprawdzaj globalne i wirtualne dyrektywy hostów w poszukiwaniu h2 lub h2c.
5. Zaktualizuj wdrożenia upstream Apache do 2.4.71 lub nowszych.
6. Zastosuj pakiety specyficzne dla dystrybucji, gdy Apache jest zarządzany przez Debian, Red Hat, Amazon Linux lub innego dostawcę systemu operacyjnego.
7. Zrestartuj Apache po zastosowaniu poprawki, aby upewnić się, że podatne procesy robocze już nie działają.
8. Zweryfikuj efektywną konfigurację serwera HTTP po remediacji.
9. Przejrzyj historyczną telemetrię w poszukiwaniu podejrzanej aktywności na systemach skierowanych na internet, które były wystawione przed załatwieniem.

Administratorzy nie powinni zakładać, że instalacja pakietu systemu operacyjnego z numerem wersji poniżej 2.4.71 oznacza, że system nadal pozostaje podatny. Dostawcy, tacy jak Red Hat, backportują poprawki zabezpieczeń do swoich wersji pakietów, więc stosowna informacja doradcza dystrybucji powinna być traktowana jako autorytatywna.

Oficjalne doradztwo Apache nie zapewnia obejścia. Jednak organizacje, które nie mogą natychmiast załatać, mogą tymczasowo usunąć HTTP/2 z wystawionych konfiguracji, eliminując dostęp do znanej podatnej ścieżki kodowej. Wiz zaleca ograniczenie serwera do HTTP/1.1, dopóki aktualizacja nie będzie mogła być wdrożona.

Na przykład:

Protocols http/1.1

Organizacje stosujące to obejście powinny sprawdzić wszystkie wirtualne hosty, ponieważ konfiguracja specyficzna dla strony może samodzielnie umożliwić h2 lub h2c.

Usunięcie HTTP/2 może mieć wpływ na wydajność aplikacji i zachowanie klientów, więc zmiana powinna być przetestowana i traktowana jako tymczasowy środek zmniejszenia ryzyka, a nie zastępstwo dla zainstalowania aktualizacji zabezpieczeń.

Strategia łagodzenia CVE-2026-119618 powinna również obejmować redukcję niepotrzebnej ekspozycji. Usługi administracyjne lub wewnętrzne Apache, które nie wymagają bezpośredniej łączności z internetem, powinny być ograniczone przez segmentację sieci, balansy obciążenia, odwrotne proxy, zasady zapory ogniowej lub prywatne adresowanie.

Organizacje korzystające z samodzielnych wydań mod_h2 między wersjami 2.0.8 a 2.0.42 wymagają szczególnej uwagi. Apache identyfikuje te wydania jako dotknięte, podczas gdy The Hacker News zgłosiło, że do chwili swojego raportu z 12 listopada nie opublikowano poprawionego samodzielnego wydania. Dysabling HTTP/2 lub migracja do pakietu Apache HTTP Server zawierającego poprawkę upstream mogą więc być koniecznymi do czasu dostępności odpowiedniej aktualizacji samodzielnej.

Jeśli zostanie odkryta podejrzana aktywność, obrońcy powinni odizolować dotknięty serwer, gdzie to operacyjnie wykonalne, oraz zachować dzienniki dostępu Apache, dzienniki błędów, dzienniki systemowe, telemetrię procesów, połączenia sieciowe oraz odpowiednie informacje o pamięci lub awariach.

Udana eksploatacja powinna być traktowana jako potencjalne naruszenie bezpieczeństwa serwera, a nie tylko awaria usługi. Śledczy powinni szukać nowych plików, webshelli, zmienionego kodu aplikacji, mechanizmów utrwalania, skradzionych poświadczeń, podejrzanego wychodzącego ruchu lub dowodów na ruch lateralny.

Poświadczenia dostępne dla procesu Apache, w tym hasła do bazy danych, klucze API, poświadczenia chmurowe, klucze prywatne TLS lub tajemnice przechowywane w konfiguracji aplikacji, powinny zostać zrewidowane i zrotowane, jeśli dowody sugerują wykonanie kodu kontrolowane przez atakującego.