# Proč nese mod_php nejvyšší riziko

> Proč tým PHP hodnotí riziko PHP2Shell u Apache s mod_php jako nejvyšší, jak mod_php poznáte a co nyní musíte záplatovat a později přepnout.

Zdroj: https://phpsos.de/cs/php2shell/mod-php-risiko/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** PHP2Shell postihuje všechny běžné provozní režimy, ale u Apache s mod_php hodnotí tým PHP riziko jako nejvyšší. Tam byl předveden exploit ještě předtím, než se vůbec spustí kód aplikace. Kdo provozuje mod_php, měl by nejprve aktualizovat PHP a Apache úplně restartovat.

## Co je mod_php?

U mod_php je PHP modulem uvnitř webového serveru Apache. Každý proces Apache obsahuje úplný interpret PHP a kód PHP spouští přímo. Tento provozní režim byl dlouho standardem a dodnes je rozšířený na starších serverech, v mnoha balíčcích distribucí a v některých obrazech Dockeru.

Alternativou je PHP-FPM: tam PHP běží jako samostatná služba s vlastními procesy a Apache nebo Nginx jen předává požadavky. Obě varianty jsou PHP2Shell postiženy, stejně jako php-cgi, FrankenPHP a LiteSpeed.

Typická prostředí s mod_php jsou starší root servery, které roky běží beze změn, standardní instalace Apache z balíčků distribucí a image Dockeru s Apache a PHP v jednom kontejneru. Kdo si není jistý, jaký provozní režim jeho server používá, měl by to ověřit, ne předpokládat.

## Proč je zranitelnost mod_php považována za obzvlášť rizikovou?

Tým PHP vydal k PHP2Shell jasné zhodnocení: u mod_php je riziko nejvyšší. Odůvodnění: tam byl předveden exploit, který zabírá ještě předtím, než se vůbec spustí kód aplikace.

Pro provozovatele to má nepříjemný důsledek. Mnoho ochranných opatření sídlí v aplikaci: bezpečnostní pluginy ve WordPressu, firewallové moduly v e-shopech, kontroly ve vlastním kódu. To vše je kód aplikace. Pokud ke zneužití dojde dříve, přicházejí pozdě.

K tomu se přidává těsné propojení: u mod_php sdílí PHP proces s Apache. Co PHP kompromituje, běží s oprávněními webového serveru a v jeho paměti. U PHP-FPM lze naproti tomu pooly oddělit vlastními uživateli pro každý web, což může důsledky průniku omezit.

Pro stanovení priorit to znamená: pokud provozujete více serverů, přijdou první na řadu ty s mod_php a u nich je následná kontrola stop obzvlášť důležitá.

Co nevíme: kolik z celosvětově napočítaných 22,6 milionu exponovaných, potenciálně zranitelných instancí používá mod_php. Spolehlivá čísla k tomu nebyla zveřejněna.

## Používá můj server mod_php?

Následující příkazy jsou čistě čtecí. Názvy služeb a příkazů se liší podle distribuce: Debian a Ubuntu používají `apache2`, rodina RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # např. php_module nebo 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, stav balíčku modulu
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # rodina RHEL
```

Pokud se neobjeví žádný modul PHP, používá Apache pravděpodobně PHP-FPM přes `proxy_fcgi`. Pak přiměřeně platí pokyny na stránce [Zabezpečení Nginx s PHP-FPM](https://phpsos.de/cs/server/nginx-php-fpm/).

## Co by provozovatelé mod_php měli udělat nyní

1. **Aktualizovat modul PHP** na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 nebo potvrzený backport vaší distribuce.
2. **Apache úplně restartovat,** ne jen znovu načíst. U mod_php je starý kód PHP v každém procesu Apache.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # rodina RHEL
ps -o pid,lstart,cmd -C apache2    # zkontrolovat čas spuštění, v RHEL: -C httpd
```

3. **Nastavit přechodná opatření, pokud aktualizace zatím nejde.** php.net uvádí mimo jiné pevné limity, které aplikace nemohou přepsat:

```apache
# Konfigurace serveru nebo VirtualHost, ne .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
```

K `memory_limit=-1` patří limit paměti přes cgroup, ne přes `RLIMIT_AS` nebo `RLIMIT_DATA`. Tato opatření nejsou úplnou ochranou; podrobnosti najdete na stránce [Okamžitá opatření, když zatím nelze záplatovat](https://phpsos.de/cs/php2shell/sofortmassnahmen-ohne-patch/). Pokud nejde ani jedno, BSI (německý Spolkový úřad pro informační bezpečnost) doporučuje webový server dočasně odpojit od sítě.

> **Jednejte ihned:**
> Pokud váš Apache s mod_php běžel mezi 17. říjnem a záplatou nechráněně na internetu, zajistěte logy od 20. října a nechte server zkontrolovat na stopy. Samotná záplata nedokazuje, že se nic nestalo.

## Střednědobě: pryč od mod_php

Po záplatě se vyplatí pohled na architekturu. Přechod na PHP-FPM s Apache `mpm_event` a `proxy_fcgi` nebo s Nginx odděluje PHP od webového serveru, umožňuje vlastní pooly a uživatele pro každý web a usnadňuje restarty i změny verzí. PHP2Shell neuzavře, ale zmenšuje plochu pro útok budoucích zranitelností.

Přechod vyžaduje plánování. Nastavení, která se dosud zadávala přes `php_value` v `.htaccess`, pod PHP-FPM už nepůsobí a musí se přesunout do poolu. Mění se uživatelé a oprávnění, složky pro nahrávání a cache mohou potřebovat nová oprávnění. V testovacím prostředí je to dobře zvládnutelné, v běžícím provozu pod časovým tlakem ne. Pokyny k přechodu najdete na stránce [Zabezpečení Apache s mod_php](https://phpsos.de/cs/server/apache-mod-php/).

## Jak konkrétně pomáhá PHP SOS?

- **Rozpoznat:** Zkontrolujeme, které servery používají mod_php a z jakého zdroje balíčků modul pochází.
- **Záplatovat a restartovat:** Prostřednictvím [služby záplatování PHP](https://phpsos.de/cs/leistungen/php-patch-service/) nasadíme aktualizaci a ověříme, že neběží žádný starý proces Apache.
- **Zabezpečit přechod:** Kde je aktualizace zablokována, nastavíme opatření z php.net v konfiguraci serveru.
- **Přepnout:** V rámci [hardeningu serveru](https://phpsos.de/cs/leistungen/server-haertung/) naplánujeme a otestujeme přechod na PHP-FPM s odděleným pooly.


## Časté dotazy

**Podle čeho poznám, zda můj Apache používá mod_php?**  
Příkazem apachectl -M nebo httpd -M uvidíte načtené moduly. Pokud je tam modul jako php_module nebo php8_module, běží PHP přímo v Apache. V Debianu a Ubuntu ukáže také a2query -m, zda je aktivní modul php.

**Chrání mě u mod_php bezpečnostní plugin ve WordPressu?**  
U této zranitelnosti ne. Podle týmu PHP byl u mod_php předveden exploit dřív, než se vůbec spustí kód aplikace. Plugin je kód aplikace a přichází tedy pozdě. Ochranu poskytuje jen aktualizace PHP s restartem Apache.

**Měl bych nyní přejít z mod_php na PHP-FPM?**  
Nejdřív záplatovat, potom přepnout. Přechod na PHP-FPM dává u většiny nastavení střednědobě smysl, protože PHP pak běží odděleně od webového serveru. PHP2Shell ale neuzavře, protože PHP-FPM je také postiženo.

## Zdroje

- [php.net: bezpečnostní oznámení](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: německý Spolkový úřad pro informační bezpečnost](https://www.bsi.bund.de/)