Apache HTTP Server z HTTP/2: krytyczna luka w mod_http2 umożliwia zdalne wykonanie kodu

Co się stało

11 listopada 2026 roku projekt Apache HTTP Server opublikował CVE-2026-119618 i wydał wersję 2.4.71. Projekt ocenia lukę jako krytyczną. Dotyczy modułu HTTP/2 mod_http2, w funkcji assign_headers(). Zasoby współdzielone nie są prawidłowo synchronizowane, gdy żądania są obsługiwane jednocześnie. Zalecenie projektu mówi, że powoduje to uszkodzenie sterty (heap corruption), które może prowadzić do zdalnego wykonania kodu.

Red Hat ocenia lukę na 9,8 w skali CVSS. Według firmy atakujący, który ma dostęp do serwera, nie potrzebuje uwierzytelnienia i mógłby przejąć pełną kontrolę nad procesem serwera. Red Hat podaje też, że publiczne badania wykazały niezawodny exploit dla domyślnej konfiguracji z włączonym mod_http2, ale nie wskazuje tych badań. Firma bezpieczeństwa Wiz poinformowała później, że exploit nie jest dostępny i nie zgłoszono żadnych ataków. Luki nie ma w katalogu CISA dotyczącym wykorzystywanych podatności, a żadne ze sprawdzonych przez nas źródeł nie donosi o atakach.

Wersja 2.4.71 usuwa także dwie inne luki:

• CVE-2026-106023 (ocena: ważna): awaria w mod_md.
• CVE-2026-109163 (ocena: niska): nadpisanie jednego bajtu na stosie w mod_vhost_alias.

Kogo to dotyczy

• Apache HTTP Server 2.4.55 do 2.4.70, ale tylko przy włączonym HTTP/2. HTTP/2 działa tylko tam, gdzie dyrektywa Protocols zawiera h2 (HTTP/2 przez TLS) lub h2c (HTTP/2 przez zwykły TCP). Dyrektywę można ustawić dla całego serwera lub dla pojedynczego wirtualnego hosta.
• Serwery, na których zainstalowano 2.4.67 w związku z wcześniejszą luką HTTP/2 CVE-2026-23918, nadal są narażone. Dotyczy to każdej wersji od 2.4.67 do 2.4.70.
• Samodzielne buildy modułu (mod_h2 z GitHuba), wersje 2.0.8 do 2.0.42. Nie ma jeszcze naprawionego wydania mod_h2, a repozytorium projektu zostało zarchiwizowane.

Te systemy nie są narażone:

• Wersje Apache wcześniejsze niż 2.4.55.
• Serwery, na których w żadnej dyrektywie Protocols nie włączono h2 ani h2c.
• Red Hat Enterprise Linux 6, 7 i 8, które nie zawierają podatnego kodu.

Stan pakietów dystrybucji na dzień 12 listopada 2026:

• RHEL 9: naprawiono w mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981).
• RHEL 10: naprawiono w mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978).
• RHEL EUS i wydania SAP: poprawki są dostępne w osobnych zaleceniach. Red Hat ocenia lukę jako Important, a nie Critical na RHEL 9 i 10, ponieważ jego buildy znacznie utrudniają atak.
• Red Hat JBoss Core Services i Red Hat Hardened Images: wymienione jako narażone, bez poprawki.
• Debian: unstable (sid) naprawiono w apache2 2.4.71-1. Tracker Debiana wymienia bookworm, trixie i forky jako podatne, bez gotowego pakietu.
• Amazon Linux 2, Amazon Linux 2023 i Amazon Linux 2027 Preview: poprawka jest w przygotowaniu.
• Ubuntu: status nie został jeszcze opublikowany.

Panele hostingowe i inne produkty dostarczające własny build Apache są narażone, jeśli ich build mieści się w tym zakresie wersji i HTTP/2 jest włączony. Ich status należy sprawdzić w zaleceniu dostawcy.

Co zrobić teraz

1. Ustal wersję Apache poleceniem apachectl -v lub httpd -v. Następnie sprawdź, czy HTTP/2 jest włączony (patrz kolejna sekcja).
2. Zaktualizuj.
   • Samodzielnie zbudowany lub oryginalny Apache: przejdź do wersji 2.4.71.
   • RHEL 9 i 10: zainstaluj aktualizacje, na przykład poleceniem dnf update mod_http2.
   • Inne dystrybucje: zainstaluj poprawiony pakiet apache2 lub httpd, gdy tylko dystrybucja go opublikuje. Sprawdź zalecenia dostawców podane poniżej.
3. Zrestartuj Apache w całości, na przykład poleceniem systemctl restart httpd lub systemctl restart apache2. Pełny restart zapewnia załadowanie zaktualizowanego modułu. Następnie upewnij się, że strony odpowiadają.
4. Jeśli nie możesz jeszcze zaktualizować: zalecenie Apache nie podaje obejścia. Wiz zaleca usunięcie h2 i h2c z każdej dyrektywy Protocols, pozostawiając Protocols http/1.1. Sprawdź ustawienie dla całego serwera oraz każdego wirtualnego hosta. Następnie przetestuj konfigurację poleceniem apachectl configtest i zrestartuj Apache. Klienci przejdą na HTTP/1.1. To jedyne dotychczasowe zabezpieczenie także dla serwerów korzystających z samodzielnych buildów mod_h2.
5. Sprawdź pozostałe serwery, w tym odwrotne proxy i serwery prowadzone dla klientów, jeśli działają na nich Apache 2.4.55 lub nowszy z włączonym HTTP/2.

Jak sprawdzić, czy jesteś narażony

• Wersja: uruchom apachectl -v (lub httpd -v). Wersje 2.4.55 do 2.4.70 są narażone. W przypadku pakietów dystrybucji porównaj z podanymi wyżej wersjami poprawionych pakietów, ponieważ dystrybucje używają własnej numeracji.
• Załadowany moduł: apachectl -M 2>/dev/null | grep http2 pokazuje, czy mod_http2 jest załadowany.
• Włączony HTTP/2: uruchom grep -RniE '^\s*Protocols' /etc/httpd /etc/apache2 2>/dev/null i wyszukaj h2 lub h2c. Uwzględnij inne katalogi, w których znajdują się pliki konfiguracyjne.
• Z zewnątrz: curl -sI --http2 https://example.com -o /dev/null -w '%{http_version}\n' wypisze 2, jeśli strona odpowiada przez HTTP/2.

Jeśli w dyrektywie Protocols żadnego z serwerów nie ma h2 ani h2c, ta luka ich nie dotyczy. Mimo to zainstaluj wersję 2.4.71 lub aktualizację swojej dystrybucji podczas zwykłej konserwacji, ponieważ usuwa ona także dwie pozostałe luki.

Źródła

• https://nvd.nist.gov/vuln/detail/CVE-2026-119618
• https://httpd.apache.org/security/vulnerabilities_24.html