# Dlaczego mod_php niesie najwyższe ryzyko

> Dlaczego zespół PHP ocenia ryzyko PHP2Shell przy Apache z mod_php najwyżej, jak rozpoznać mod_php i co teraz załatać oraz przestawić na serwerze.

Źródło: https://phpsos.de/pl/php2shell/mod-php-risiko/  
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:** 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`.

```bash
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](https://phpsos.de/pl/server/nginx-php-fpm/).

## Co operatorzy mod_php powinni teraz zrobić

1. **Zaktualizować moduł PHP** do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do potwierdzonego backportu Państwa dystrybucji.
2. **Całkowicie zrestartować Apache,** a nie tylko przeładować. Przy mod_php stary kod PHP tkwi w każdym procesie Apache.

```bash
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
```

3. **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ć:

```apache
# 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ć](https://phpsos.de/pl/php2shell/sofortmassnahmen-ohne-patch/). Jeśli jedno i drugie nie jest możliwe od razu, BSI zaleca czasowe odłączenie serwera WWW od sieci.

> **Działać natychmiast:**
> 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](https://phpsos.de/pl/server/apache-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](https://phpsos.de/pl/leistungen/php-patch-service/) 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](https://phpsos.de/pl/leistungen/server-haertung/) 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.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)](https://www.bsi.bund.de/)