# Zabezpieczenie Apache z mod_php > Apache mod_php po PHP2Shell: rozpoznaj tryb pracy, załataj moduł PHP, w pełni zrestartuj Apache i przygotuj przejście na PHP-FPM. Instrukcja dla administratorów. Źródło: https://phpsos.de/pl/server/apache-mod-php/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **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](https://phpsos.de/pl/php2shell/mod-php-risiko/). ## 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. ```bash # 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ą. ```bash # 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. > **Działać natychmiast:** > Jeśli dla Państwa wersji PHP nie ma jeszcze poprawki, BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca czasowe odłączenie serwera WWW od sieci. Przy mod_php ma to szczególne znaczenie, ponieważ atak może zadziałać przed kodem aplikacji. ## Ś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ć. ```apache # Przykład: w konfiguracji VirtualHost lub ogólnoserwerowej php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` 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](https://phpsos.de/pl/php2shell/sofortmassnahmen-ohne-patch/). ## 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](https://phpsos.de/pl/server/nginx-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](https://phpsos.de/pl/leistungen/php-patch-service/) 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](https://phpsos.de/pl/leistungen/server-haertung/) planujemy i testujemy przejście na PHP-FPM z rozdzielonymi pulami. ## Częste pytania **Jak rozpoznać, że mój serwer używa mod_php?** Jeśli Apache ma załadowany moduł PHP, widnieje on na liście modułów jako php_module lub z numerem wersji w nazwie. Dodatkowo wynik phpinfo pokazuje w pozycji Server API wpis Apache 2.0 Handler. Taki plik testowy proszę natychmiast usunąć. **Dlaczego mod_php jest przy PHP2Shell szczególnie krytyczne?** Według zespołu PHP ryzyko jest tam najwyższe; pokazano exploit, zanim w ogóle zacznie działać kod aplikacji. Dlatego nie chroni nawet dobrze utrzymana aplikacja. Szybka aktualizacja ma więc najwyższy priorytet. **Czy po aktualizacji wystarczy przeładować Apache?** Bezpieczny jest pełny restart usługi, ponieważ PHP jako moduł tkwi w procesach Apache. Potem proszę sprawdzić czas startu wszystkich procesów Apache. Nie mogą zostać procesy starsze niż aktualizacja. **Czy przejście na PHP-FPM jest pracochłonne?** Zwykle da się je dobrze zaplanować: zainstalować PHP-FPM, utworzyć pule, przełączyć Apache na proxy_fcgi i zmienić prefork na inny MPM. Proszę przetestować to wcześniej na kopii środowiska. ## Źródła - [php.net: komunikaty bezpieczeństwa](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI](https://www.bsi.bund.de/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)