Zabezpieczenie Apache z mod_php

Krótko: W Apache z mod_php PHP działa bezpośrednio w serwerze WWW. Zespół PHP ocenia ryzyko związane z PHP2Shell właśnie w tym trybie pracy jako najwyższe, ponieważ pokazano exploit, zanim w ogóle zacznie działać kod aplikacji. Proszę natychmiast załatać, w pełni zrestartować Apache, a potem zaplanować przejście na PHP-FPM.

Czym jest mod_php i dlaczego ma teraz znaczenie

W mod_php Apache ładuje PHP jako moduł do każdego własnego procesu roboczego. Każde żądanie do pliku PHP jest wykonywane bezpośrednio w tym procesie. Przez długi czas był to standard i łatwo go skonfigurować. Oznacza to jednak również: wszystkie strony na serwerze działają z tym samym użytkownikiem, a PHP dzieli proces z serwerem WWW.

PHP2Shell obejmuje luki CVE-2026-109618 i CVE-2026-109619, obie z wynikiem CVSS v4.0 9.2. W przypadku drugiej wewnętrzny stan żądania może po zwolnieniu pamięci pozostać i zostać użyty przez późniejsze żądanie w tym samym procesie. Dla mod_php zespół PHP stwierdził najwyższe ryzyko. Tło i ocenę podaje artykuł Dlaczego mod_php niesie najwyższe ryzyko.

Rozpoznanie Apache mod_php i kontrola wersji

Proszę najpierw sprawdzić, czy Państwa Apache w ogóle używa mod_php. Poniższe polecenia tylko odczytują. Nazwy poleceń i pakietów różnią się zależnie od dystrybucji i są przykładami.

# Debian/Ubuntu: załadowane moduły
apache2ctl -M 2>/dev/null | grep -i php

# Rodzina RHEL
httpd -M 2>/dev/null | grep -i php

# Który MPM jest aktywny? mod_php wymaga prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Stan pakietu modułu (przykłady)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Jeśli pojawia się moduł taki jak php_module, działa mod_php. Sama wyświetlana wersja PHP nie jest dowodem poprawki, ponieważ dystrybucje często instalują poprawki jako backport. Wersje projektu PHP z usuniętą luką to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. W przypadku pakietów dystrybucji liczy się dziennik zmian z numerami CVE.

Poprawka i pełny restart Apache

Proszę zainstalować aktualizację przez menedżer pakietów. Ponieważ PHP tkwi w procesie Apache, potem musi zrestartować się cała usługa. Przeładowanie konfiguracji nie jest tu bezpieczną drogą.

# Debian/Ubuntu
systemctl restart apache2

# Rodzina RHEL
systemctl restart httpd

# Kontrola: czas startu wszystkich procesów Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Wszystkie procesy Apache muszą pokazywać czas startu późniejszy niż aktualizacja. Jeśli na tym samym serwerze działa dodatkowo PHP-FPM lub php-cgi, proszę zrestartować także te usługi.

Środki przejściowe w konfiguracji Apache

php.net podaje środki przejściowe, które zmniejszają ryzyko, ale nie dają pełnej ochrony. W mod_php wartości ustawia się przez php_admin_value lub php_admin_flag w konfiguracji Apache, aby .htaccess i aplikacje nie mogły ich nadpisać.

# Przykład: w konfiguracji VirtualHost lub ogólnoserwerowej
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

Przy funkcji uploadu php.net podaje post_max_size = 32M, a upload_max_filesize niższe. W PHP 8.5 dochodzi fatal_error_backtraces=0. Wskazówkę dotyczącą memory_limit=-1 proszę wdrażać tylko razem z limitem pamięci dla usługi przez cgroups, na przykład przez MemoryMax w uzupełnieniu systemd, a nie przez RLIMIT_AS czy RLIMIT_DATA. Potem proszę w pełni zrestartować Apache. Wszystkie środki w skrócie: Środki doraźne bez poprawki.

Droga odejścia od mod_php

Po doraźnej poprawce opłaca się przejście na PHP-FPM. PHP działa wtedy w osobnych procesach, oddzielonych od serwera WWW. Każda strona może dostać własną pulę z własnym użytkownikiem, limity można ustawiać dla każdej puli, a restarty dotyczą tylko PHP. Apache łączy się z PHP-FPM przez mod_proxy_fcgi i może wtedy zamiast prefork używać nowocześniejszego MPM, takiego jak event.

Proszę zaplanować zmianę w środowisku testowym: utworzyć pule dla każdej strony, dostosować prawa do plików do nowych użytkowników, przenieść wpisy .htaccess z php_value do ustawień puli, przeprowadzić testy obciążeniowe. Jak wygląda poprawna konfiguracja, pokazuje artykuł Zabezpieczenie Nginx z PHP-FPM; zasady obowiązują tak samo dla Apache z PHP-FPM.

Niezależnie od trybu pracy obowiązuje: poprawka nie usuwa już wprowadzonego szkodliwego oprogramowania. Proszę zachować logi od 20.10.2026 i sprawdzić serwer pod kątem śladów.

Przy szukaniu śladów na serwerach z mod_php warto spojrzeć na wspólnego użytkownika. Ponieważ wszystkie strony działają pod użytkownikiem Apache, na przykład www-data lub apache, atakujący, który przejął jedną stronę, zwykle może także czytać i zmieniać pliki pozostałych. Dlatego proszę sprawdzić nie tylko stronę, która wydaje się podejrzana, ale wszystkie katalogi główne dokumentów na serwerze. Szczególną uwagę proszę zwrócić na pliki PHP z niedawną datą zmiany w katalogach uploadu i cache, na kod programu należący do użytkownika Apache oraz na nieznane wpisy w crontabie tego użytkownika. Jeśli coś Państwo znajdą, proszę najpierw zabezpieczyć stan systemu i nie usuwać pochopnie, aby przyczynę dało się później odtworzyć.

Jak konkretnie pomaga PHP SOS?

• Sprawdzamy tryb pracy, MPM i stan pakietów i oceniamy, czy Państwa serwer rzeczywiście jest załatany.
• Przez usługę aktualizacji PHP instalujemy aktualizację, w pełni restartujemy Apache i dokumentujemy dowód.
• Do czasu poprawki ustawiamy środki przejściowe w sposób niemożliwy do nadpisania i ograniczamy pamięć na poziomie usługi.
• W ramach utwardzania serwerów planujemy i testujemy przejście na PHP-FPM z rozdzielonymi pulami.

Częste pytania

Źródła

• php.net: komunikaty bezpieczeństwa
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets