Krótko: PHP2Shell dotyczy wszystkich powszechnych trybów pracy, ale przy Apache z mod_php zespół PHP ocenia ryzyko najwyżej. Pokazano tam exploit, zanim w ogóle uruchomi się kod aplikacji. Kto eksploatuje mod_php, powinien najpierw zaktualizować PHP i całkowicie zrestartować Apache.
Czym jest mod_php?
W mod_php PHP jest modułem wewnątrz serwera WWW Apache. Każdy proces Apache zawiera pełny interpreter PHP i wykonuje kod PHP bezpośrednio. Ten tryb pracy był długo standardem i do dziś jest rozpowszechniony na starszych serwerach, w wielu pakietach dystrybucji i w niektórych obrazach Docker.
Alternatywą jest PHP-FPM: tam PHP działa jako osobna usługa z własnymi procesami, a Apache lub Nginx jedynie przekazuje żądania. Oba warianty są dotknięte przez PHP2Shell, podobnie jak php-cgi, FrankenPHP i LiteSpeed.
Typowe środowiska z mod_php to starsze serwery root, które od lat działają bez zmian, standardowe instalacje Apache z pakietów dystrybucji oraz obrazy Docker z Apache i PHP w jednym kontenerze. Kto nie wie na pewno, jakiego trybu pracy używa jego serwer, powinien to sprawdzić, zamiast zakładać.
Dlaczego luka w mod_php uchodzi za szczególnie ryzykowną?
Zespół PHP wydał w sprawie PHP2Shell jasną ocenę: przy mod_php ryzyko jest najwyższe. Uzasadnienie: pokazano tam exploit, który działa, zanim w ogóle uruchomi się kod aplikacji.
Dla operatorów ma to niewygodną konsekwencję. Wiele środków ochronnych znajduje się w aplikacji: wtyczki bezpieczeństwa w WordPressie, moduły firewalla w sklepach, kontrole we własnym kodzie. Wszystkie one są kodem aplikacji. Jeśli wykorzystanie luki następuje wcześniej, działają za późno.
Dochodzi ścisłe powiązanie: przy mod_php PHP dzieli proces z Apache. To, co PHP przejmie, działa z uprawnieniami serwera WWW i w jego pamięci. Przy PHP-FPM można natomiast rozdzielić pule z oddzielnymi użytkownikami dla każdej strony, co może ograniczyć skutki włamania.
Dla ustalania priorytetów oznacza to: jeśli eksploatują Państwo kilka serwerów, te z mod_php są na pierwszym miejscu, a przy nich szczególnie ważne jest późniejsze sprawdzenie śladów.
Czego nie wiemy: ile z naliczonych na świecie 22,6 miliona wystawionych na dostęp, potencjalnie podatnych instancji używa mod_php. Wiarygodne liczby na ten temat nie zostały opublikowane.
Czy mój serwer używa mod_php?
Poniższe polecenia służą wyłącznie do odczytu. Nazwy usług i poleceń różnią się zależnie od dystrybucji: Debian i Ubuntu używają apache2, rodzina RHEL httpd.
apachectl -M 2>/dev/null | grep -i php # np. php_module lub php8_module
httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php # Debian/Ubuntu
apt policy libapache2-mod-php8.3 # Debian/Ubuntu, stan pakietu modułu
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # rodzina RHEL
Jeśli nie pojawia się żaden moduł PHP, Apache używa prawdopodobnie PHP-FPM przez proxy_fcgi. Wtedy odpowiednio obowiązują wskazówki ze strony Zabezpieczanie Nginx z PHP-FPM.
Co operatorzy mod_php powinni teraz zrobić
- Zaktualizować moduł PHP do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do potwierdzonego backportu Państwa dystrybucji.
- Całkowicie zrestartować Apache, a nie tylko przeładować. Przy mod_php stary kod PHP tkwi w każdym procesie Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # rodzina RHEL
ps -o pid,lstart,cmd -C apache2 # sprawdzić czas startu, w RHEL: -C httpd
- Ustawić środki przejściowe, jeśli aktualizacja jeszcze nie jest możliwa. php.net podaje między innymi stałe limity, których aplikacje nie mogą nadpisać:
# Konfiguracja serwera lub VirtualHost, nie .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Przy memory_limit=-1 potrzebny jest limit pamięci przez cgroup, a nie przez RLIMIT_AS czy RLIMIT_DATA. Te środki nie są pełną ochroną; szczegóły na stronie Środki natychmiastowe, gdy nie można jeszcze załatać. Jeśli jedno i drugie nie jest możliwe od razu, BSI zaleca czasowe odłączenie serwera WWW od sieci.
Jeśli Państwa Apache z mod_php działał między 17 października a poprawką niezabezpieczony w internecie, proszę zabezpieczyć logi od 20 października i kazać sprawdzić serwer pod kątem śladów. Sama poprawka nie dowodzi, że nic się nie stało.
Średnioterminowo: odejście od mod_php
Po załataniu warto spojrzeć na architekturę. Przejście na PHP-FPM z Apache mpm_event i proxy_fcgi lub z Nginx oddziela PHP od serwera WWW, pozwala na własne pule i użytkowników dla każdej strony oraz ułatwia restarty i zmiany wersji. Nie zamyka PHP2Shell, ale zmniejsza powierzchnię ataku przyszłych luk.
Przejście wymaga planowania. Ustawienia, które dotąd były ustawiane przez php_value w .htaccess, nie działają pod PHP-FPM i muszą trafić do puli. Zmieniają się użytkownicy i uprawnienia, a katalogi uploadów i pamięci podręcznej mogą potrzebować nowych uprawnień. W środowisku testowym jest to dobrze opanowalne, w bieżącej eksploatacji pod presją czasu już nie. Wskazówki dotyczące przejścia znajdą Państwo na stronie Zabezpieczanie Apache z mod_php.
Jak konkretnie pomaga PHP SOS?
- Rozpoznanie: Sprawdzamy, które serwery używają mod_php i z jakiego źródła pakietów pochodzi moduł.
- Łatanie i restart: Przez usługę łatania PHP instalujemy aktualizację i kontrolujemy, że żaden stary proces Apache już nie działa.
- Zabezpieczenie okresu przejściowego: Tam, gdzie aktualizacja jest zablokowana, ustawiamy środki z php.net w konfiguracji serwera.
- Przestawienie: W ramach utwardzania serwera planujemy i testujemy przejście na PHP-FPM z oddzielnymi pulami.
Częste pytania
Po czym poznam, czy mój Apache używa mod_php?
Poleceniem apachectl -M lub httpd -M widać załadowane moduły. Jeśli stoi tam moduł taki jak php_module lub php8_module, PHP działa bezpośrednio w Apache. W Debianie i Ubuntu także a2query -m pokazuje, czy aktywny jest moduł php.
Czy wtyczka bezpieczeństwa w WordPressie chroni mnie przy mod_php?
Przy tej luce nie. Według zespołu PHP przy mod_php pokazano exploit, zanim w ogóle uruchomi się kod aplikacji. Wtyczka jest kodem aplikacji i działa więc za późno. Ochronę daje tylko aktualizacja PHP z restartem Apache.
Czy powinienem teraz przejść z mod_php na PHP-FPM?
Najpierw załatać, potem przestawić. Przejście na PHP-FPM jest dla większości konfiguracji średnioterminowo sensowne, ponieważ PHP działa wtedy oddzielnie od serwera WWW. Nie zamyka jednak PHP2Shell, bo PHP-FPM jest również dotknięte.