Na początku maja 2026 roku Apache Software Foundation wydała wersję 2.4.67 swojego serwera WWW, łatając kilka podatności. Najpoważniejsza z nich, oznaczona jako CVE-2026-23918 i wyceniona na 8.8 punktu w skali CVSS, to błąd typu „double free” w obsłudze protokołu HTTP/2. W praktyce oznacza to, że atakujący może jednym połączeniem i dwiema ramkami protokołu doprowadzić do awarii procesu obsługującego ruch — bez logowania, bez znajomości żadnego adresu URL i bez wysyłania spreparowanych nagłówków. Na części konfiguracji ta sama luka prowadzi dalej, aż do zdalnego wykonania kodu. Co ciekawe dla polskiego czytelnika, podatność wykryli i zgłosili dwaj polscy specjaliści — Bartłomiej Dmitruk, współzałożyciel Striga.ai, oraz Stanisław Strzałkowski, badacz związany z ISEC.pl.
Na czym polega błąd
Sercem problemu jest moduł mod_http2, czyli komponent Apache odpowiedzialny za obsługę HTTP/2. Luka znajduje się w ścieżce sprzątania strumieni w pliku h2_mplx.c. Wyzwala się w bardzo konkretnym scenariuszu: klient wysyła ramkę HEADERS, a zaraz po niej ramkę RST_STREAM z niezerowym kodem błędu na tym samym strumieniu — zanim multiplekser zdąży zarejestrować ten strumień.
W takiej sytuacji dwie funkcje zwrotne biblioteki nghttp2 uruchamiają się jedna po drugiej i obie trafiają do tej samej procedury czyszczącej. Efekt jest taki, że ten sam wskaźnik na strukturę strumienia zostaje dwukrotnie dodany do tablicy obiektów przeznaczonych do zwolnienia. Gdy serwer później przechodzi przez tę tablicę i zwalnia pamięć, drugie zwolnienie trafia w obszar, który już nie istnieje. To klasyczny błąd podwójnego zwolnienia pamięci — jedna z najgroźniejszych kategorii błędów w kodzie pisanym w języku C.
DoS w dwóch ramkach, RCE jako scenariusz gorszy
Według odkrywców luka prowadzi do dwóch różnych skutków. Pierwszy to odmowa usługi i jest trywialny do wywołania. Wystarczy jedno połączenie TCP i dwie ramki — proces roboczy Apache się wykłada. Serwer co prawda uruchamia go ponownie, ale wszystkie żądania obsługiwane w tym momencie przez zabity proces przepadają, a atak można podtrzymywać tak długo, jak długo napastnik wysyła pakiety. Dla witryny pod obciążeniem oznacza to realny paraliż.
Drugi, znacznie poważniejszy scenariusz to zdalne wykonanie kodu. Badacze zbudowali działający proof of concept na architekturze x86_64. Technika polega na umieszczeniu spreparowanej struktury w zwolnionym adresie pamięci i wskazaniu jej procedury sprzątającej na funkcję system(). Ścieżka RCE nie działa jednak wszędzie — wymaga konkretnego alokatora pamięci (APR z alokatorem mmap), który jest domyślny na systemach z rodziny Debiana oraz w oficjalnym obrazie Docker serwera httpd. Warto też wiedzieć, że tryb prefork modułu MPM nie jest podatny — problem dotyczy konfiguracji wielowątkowych.
Kogo to dotyczy i dlaczego to ważne
Skala potencjalnego zagrożenia jest duża, bo mod_http2 wchodzi w skład domyślnych buildów Apache, a HTTP/2 jest dziś powszechnie włączony w środowiskach produkcyjnych. Mówimy więc o ogromnej liczbie serwerów WWW na całym świecie — od pojedynczych blogów po panele aplikacji firmowych. Podatna jest konkretnie wersja 2.4.66; poprawkę zawiera 2.4.67.
To dobra okazja, by przypomnieć prostą prawdę: serwer WWW, nawet zaktualizowany pod kątem aplikacji, bywa zapomniany na poziomie samego oprogramowania httpd. Wiele instalacji działa latami bez przeglądu wersji, a HTTP/2 włączono kiedyś „dla wydajności” i nikt do tego nie wraca.
Co powinien zrobić administrator
Najważniejsza rzecz to aktualizacja Apache do wersji 2.4.67 lub nowszej. Jeśli korzystasz z pakietów dystrybucji (Debian, Ubuntu, RHEL), sprawdź, czy poprawka została już zbackportowana do paczki — producenci często łatają bez podnoszenia pełnego numeru wersji. Wersję sprawdzisz poleceniem apache2 -v lub httpd -v.
Jeśli z jakiegoś powodu nie możesz natychmiast zaktualizować serwera, rozważ tymczasowe wyłączenie modułu mod_http2 albo samego HTTP/2 w konfiguracji — witryna wróci do HTTP/1.1, co dla większości stron jest w pełni akceptowalne jako rozwiązanie pomostowe. Alternatywą jest przełączenie serwera na tryb prefork, który nie jest podatny, choć to zmiana o szerszych konsekwencjach wydajnościowych.
Warto też zajrzeć w logi i monitoring pod kątem nietypowo częstych restartów procesów roboczych — to może być sygnał próby ataku DoS. Jeśli przed Apache stoi reverse proxy lub WAF, sprawdź, czy nie da się na nim ograniczyć liczby strumieni RST_STREAM na połączenie.
Podsumowanie
CVE-2026-23918 to przypadek, w którym pojedynczy błąd zarządzania pamięcią w popularnym module zamienia się w narzędzie do paraliżowania serwerów, a w niesprzyjających okolicznościach — do ich przejęcia. Dobra wiadomość jest taka, że łatka istnieje i jest dostępna od początku maja, a sama aktualizacja do 2.4.67 zamyka problem. Zła jest taka, że serwery WWW należą do najczęściej zaniedbywanych elementów infrastruktury. Jeśli administrujesz choćby jedną stroną na Apache, dzisiaj jest dobry dzień, żeby sprawdzić numer wersji. Na osłodę warto odnotować, że tę konkretną lukę świat zawdzięcza dwóm polskim badaczom — dowód, że polska scena bezpieczeństwa potrafi znajdować błędy w oprogramowaniu, z którego korzysta cały internet.
źródło: https://thehackernews.com/2026/05/critical-apache-http2-flaw-cve-2026.html