Krytyczna luka w serwerze Apache. Jak sprawdzić i załatać

Apache HTTP Server w wersjach od 2.4.55 do 2.4.70 ma krytyczną lukę w module HTTP/2, która według Apache może prowadzić do zdalnego wykonania kodu, więc właściciel serwera z Apache i włączonym HTTP/2 powinien dziś sprawdzić wersję. Poprawkę trzeba zainstalować, gdy tylko da ją dystrybucja. Projekt Apache wydał wersję 2.4.71 z poprawką 11 listopada 2026 roku. Red Hat tego samego dnia opublikował poprawione pakiety dla RHEL 9 i 10. Debian 12 listopada wydał poprawkę dla Debiana 13 (komunikat DSA-6620-1). Wieczorem 12 listopada poprawki wydały też Debian dla Debiana 12 (komunikat DLA-4902-1) i Ubuntu (komunikat USN-9090-1). Stan na 13 listopada 2026 roku, godz. 6:00.

Co naprawia Apache 2.4.71 i kto znalazł lukę

Luka CVE-2026-119618 siedzi w module mod_http2, który obsługuje protokół HTTP/2, w funkcji assign_headers(). Strona podatności Apache HTTP Server 2.4 opisuje ją jako błąd synchronizacji przy współbieżnym korzystaniu ze wspólnego zasobu. Błąd uszkadza pamięć sterty i “can lead to RCE”, czyli może pozwolić na uruchomienie kodu na serwerze. Apache ocenia ją jako krytyczną. Dotyczy też samodzielnego modułu mod_h2 z GitHuba w wersjach od 2.0.8 do 2.0.42.

Red Hat wyjaśnia mechanizm prościej. HTTP/2 pozwala klientowi wysłać wiele żądań naraz jednym połączeniem, a moduł obsługuje je w kilku wątkach. Przez błąd jeden wątek może zapisać coś w pamięci, która należy do innego. Według bazy luk Red Hata atakujący, który dociera do serwera, mógłby w ten sposób wykonać polecenia bez logowania. Red Hat wycenił lukę na 9,8 na 10 w skali oceny zagrożenia CVSS 3.1.

Apache wymienia dwóch niezależnych znalazców. Pierwszy to “Anthropic’s OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ”, czyli skaner firmy Anthropic badający kod otwartoźródłowy, który zgłosił błąd 26 października. Drugi to Anthony Weems i Simon Scannell z zespołu Google Cloud Vulnerability Research, ze zgłoszeniem z 3 listopada. Wersja 2.4.71 łata jeszcze dwie luki. CVE-2026-106023 w module mod_md ma ocenę ważną (“important”) i wywraca proces potomny, a CVE-2026-109163 w mod_vhost_alias ocenę niską (“low”).

Uwaga na wersję 2.4.70. Apache wydał ją 6 listopada, więc kto zaktualizował serwer w zeszłym tygodniu, nadal ma wersję z zakresu podatnego.

Czy luka w Apache jest już wykorzystywana

W sprawdzonych źródłach nie znaleźliśmy potwierdzenia ataków z użyciem tej luki. Apache nic o nich nie pisze, a w katalogu aktywnie wykorzystywanych luk amerykańskiej agencji CISA nie ma wpisu. Ostatnia wersja katalogu, sprawdzona 13 listopada o 6:00, pochodzi jednak z 10 listopada, sprzed ogłoszenia.

Źródła różnią się w ocenie, czy istnieje działający exploit, czyli kod wykorzystujący lukę. Wiz napisał 11 listopada, że w chwili publikacji “no exploit is available” i nie ma doniesień o atakach. Red Hat podaje coś innego: według niego publiczne badania pokazały niezawodny exploit. Działa on na serwerze w domyślnej konfiguracji z włączonym mod_http2. Rozsądniej założyć, że czas na aktualizację liczy się w dniach.

Kogo dotyczy luka: wersja i włączone HTTP/2

Podatny jest serwer, który obsługuje HTTP/2 i ma niezałatany moduł mod_http2. W wydaniach projektu Apache chodzi o wersje od 2.4.55 do 2.4.70. Dystrybucje łatają jednak pakiety bez zmiany wersji bazowej, więc przy pakiecie z Debiana, Ubuntu czy RHEL liczy się komunikat dystrybucji i pełny numer pakietu. Red Hat pisze wprost, że luka dotyczy serwerów z HTTP/2 włączonym dyrektywą Protocols (h2 albo h2c). Serwery obsługujące tylko HTTP/1.1 nie są podatne.

Domyślnie Apache obsługuje tylko HTTP/1.1. Według dokumentacji dyrektywy Protocols HTTP/2 trzeba włączyć wpisem w rodzaju Protocols h2 http/1.1. W praktyce zależy to od dystrybucji:

• Debian: w plikach pakietu apache2 świeża instalacja nie włącza modułu http2. Polecenie a2enmod http2 włącza go razem z plikiem http2.conf, który zawiera Protocols h2 h2c http/1.1. Po włączeniu modułu HTTP/2 działa więc na wszystkich hostach, które nie mają własnej dyrektywy Protocols.
• RHEL 9 i pochodne: w plikach pakietów CentOS Stream 9 httpd zaleca doinstalowanie mod_http2. Ten pakiet ładuje moduł plikiem 10-h2.conf. Domyślne pliki konfiguracji nie ustawiają jednak Protocols, więc HTTP/2 działa dopiero po dopisaniu tej dyrektywy.

Wiz podaje, że 64% środowisk chmurowych ma zasoby z podatną wersją, a 51% ma instancje wystawione do internetu. Zastrzega przy tym, że te liczby nie uwzględniają konfiguracji, czyli tego, czy HTTP/2 jest włączone.

Jak sprawdzić wersję Apache i czy mod_http2 jest włączony

Wersję pokazuje opcja -v, a listę załadowanych modułów opcja -M, obie opisane w dokumentacji programu httpd. W Debianie i Ubuntu wywołuje się je przez apache2ctl, który według dokumentacji pakietu Debiana przygotowuje środowisko potrzebne domyślnej konfiguracji.

Debian i Ubuntu

apache2ctl -v
apache2ctl -M | grep http2
apt-cache policy apache2
grep -ri "^\s*Protocols" /etc/apache2/

Jeśli druga komenda wypisze http2_module, konfiguracja ładuje moduł. Ostatnia znajdzie wpisy Protocols, także w nieaktywnych plikach, na przykład w mods-available. Liczą się tylko pliki, które konfiguracja faktycznie dołącza. Wersja z apache2ctl -v to wersja bazowa projektu. O poprawce w Debianie i Ubuntu decyduje pełny numer pakietu z apt-cache policy.

RHEL, AlmaLinux, Rocky Linux

httpd -v
httpd -M | grep http2
rpm -q mod_http2
grep -ri "^\s*Protocols" /etc/httpd/

W RHEL 9 i 10 poprawka przychodzi w pakiecie mod_http2, nie httpd, więc liczy się wynik rpm -q mod_http2.

Z zewnątrz, bez logowania na serwer, sprawdzisz, czy strona w ogóle rozmawia po HTTP/2. Polecenie wpisane na własnym komputerze curl -sI --http2 https://twojadomena.pl -o /dev/null -w '%{http_version}\n' wypisze wtedy 2. Test dotyczy jednego adresu, a wynik 2 za serwerem pośredniczącym, na przykład CDN, dotyczy tylko tego serwera. Apache za nim trzeba sprawdzić osobno.

Stan pakietów w Debianie, Ubuntu i RHEL

Debian 13, Debian 12 i wspierane wydania Ubuntu mają poprawione pakiety od 12 listopada, a RHEL 9 i 10 od 11 listopada. Wiersze Debiana i Ubuntu to odczyt z 13 listopada, godz. 6:00, wiersze RHEL z 12 listopada, godz. 5:27-5:35:

Dane Debiana pochodzą z systemu śledzenia luk Debiana (zgłoszenie nr 1153732) i komunikatu DSA-6620-1 z 12 listopada. Komunikat wymienia poprawkę tylko dla Debiana 13 (2.4.71-1~deb13u1). Debian 12 jest już pod opieką zespołu Debian LTS, który wieczorem 12 listopada wydał komunikat DLA-4902-1 z pakietem 2.4.71-1~deb12u1. Ubuntu tego samego dnia wydało komunikat USN-9090-1. Według niego luka dotyczy Ubuntu 20.04, 22.04, 24.04, 26.04 i 26.10, także tam, gdzie wersja bazowa Apache jest starsza niż 2.4.55. Poprawione pakiety to 2.4.52-1ubuntu4.27 w 22.04, 2.4.58-1ubuntu8.19 w 24.04, 2.4.66-2ubuntu2.8 w 26.04 i 2.4.68-1ubuntu6.2 w 26.10. Ubuntu 20.04 dostaje poprawkę tylko w płatnym Ubuntu Pro. Red Hat dla RHEL 9 i 10 obniżył ocenę do “Important”. Jego pakiety przydzielają pamięć każdemu strumieniowi HTTP/2 osobnym mechanizmem, co według firmy znacząco utrudnia atak. RHEL 8 ma według Red Hata zbyt starą wersję modułu, żeby zawierała podatny kod.

Tam, gdzie pakiet z poprawką już jest, wystarczy zwykła aktualizacja i restart Apache. Na Debianie to sudo apt update && sudo apt upgrade, a potem sudo apache2ctl -t && sudo systemctl restart apache2. Na RHEL to sudo dnf upgrade mod_http2, a potem sudo httpd -t && sudo systemctl restart httpd. Podobną ścieżkę opisywaliśmy przy luce w APT w Debianie i Ubuntu.

Obejście do czasu aktualizacji: wyłączenie HTTP/2

Apache nie podał oficjalnego obejścia, a Red Hat nie ma na stronie luki sekcji “Mitigation”. Z opisu Red Hata wynika jednak, że serwer obsługujący tylko HTTP/1.1 nie jest podatny. Wiz zaleca wprost, by do czasu aktualizacji ograniczyć protokoły do HTTP/1.1. Przeglądarki przejdą wtedy na HTTP/1.1, a strona będzie działać dalej.

Na Debianie i Ubuntu wyłączysz moduł razem z jego plikiem konfiguracji:

1. Wpisz sudo a2dismod http2.
2. Sprawdź konfigurację i zrestartuj serwer tylko po udanym teście: sudo apache2ctl -t && sudo systemctl restart apache2. Pełny restart przerwie bieżące połączenia, ale nie zostawi starych procesów z załadowanym modułem, co przy przeładowaniu graceful jest możliwe przez pewien czas.
3. Sprawdź stan usługi: systemctl status apache2.
4. Uruchom sudo apache2ctl -M i upewnij się, że polecenie zakończyło się bez błędu, a lista nie zawiera http2_module. Ten wynik potwierdza konfigurację, a działające procesy zmienia dopiero pełny restart.

Na RHEL i pochodnych ustaw Protocols http/1.1 albo zakomentuj linię LoadModule w /etc/httpd/conf.modules.d/10-h2.conf. Potem wykonaj sudo httpd -t && sudo systemctl restart httpd, czyli restart tylko po udanym teście konfiguracji. Przy pierwszym sposobie uważaj na wirtualne hosty. Według dokumentacji Apache Protocols w sekcji <VirtualHost> zastępuje ustawienie globalne. Host z własnym Protocols h2 http/1.1 zostanie więc z HTTP/2. Wyłączenie modułu działa na wszystkie hosty, bo Apache ignoruje protokoły, których nie obsługuje żaden załadowany moduł.

FAQ

Czy luka dotyczy stron na hostingu współdzielonym?

To zależy od serwera, na którym hosting trzyma stronę, i tylko dostawca może to sprawdzić. Część firm hostingowych używa Apache, część LiteSpeeda albo nginx, które nie korzystają z modułu mod_http2 Apache. Jeśli masz stronę na hostingu i nie zarządzasz serwerem, zapytaj dostawcę, czy jego serwery z Apache dostały poprawkę CVE-2026-119618.

Czy wystarczy zaktualizować WordPressa albo PHP?

Nie. Luka siedzi w serwerze WWW, który uruchamia aplikację, więc aktualizacja WordPressa czy PHP jej nie usuwa. Warto jednak pilnować także ich, na przykład wersji PHP na stronie.

{ dla firm }

Co możemy zrobić dla Twojej firmy?

Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.

strony i sklepyaplikacjeKSeF i integracjeautomatyzacjeagenci AISEO

Zobacz, co robimy dla firm → Software house, który prowadzi ten blog

Podsumowanie

Luka CVE-2026-119618 w module HTTP/2 Apache HTTP Server dotyczy wersji od 2.4.55 do 2.4.70, także wydanej 6 listopada. Według Apache może prowadzić do zdalnego wykonania kodu. Znalazły ją niezależnie skaner Anthropic badający kod otwartoźródłowy i badacze Google Cloud. W sprawdzonych źródłach nie ma potwierdzenia ataków. Red Hat pisze jednak o publicznie pokazanym exploicie, a Wiz o jego braku, więc nie warto czekać. Sprawdź poleceniem -v wersję, a poleceniem -M moduł http2_module, a przy pakietach dystrybucji pełny numer pakietu. Na RHEL 9 i 10 zainstaluj nowy mod_http2, a na Debianie 13 pakiet apache2 2.4.71-1~deb13u1. Na Debianie 12 zainstaluj pakiet 2.4.71-1~deb12u1, a na Ubuntu wersję z komunikatu USN-9090-1. Jeśli na czas oczekiwania wyłączyłeś HTTP/2 (a2dismod http2), po aktualizacji włącz je z powrotem. Stan na 13 listopada 2026 roku, godz. 6:00.