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.
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.
Co by provozovatelé mod_php měli udělat nyní
- Aktualizovat modul PHP na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 nebo potvrzený backport vaší distribuce.
- Apache úplně restartovat, ne jen znovu načíst. U mod_php je starý kód PHP v každém procesu Apache.
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
- Nastavit přechodná opatření, pokud aktualizace zatím nejde. php.net uvádí mimo jiné pevné limity, které aplikace nemohou přepsat:
# 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. Pokud nejde ani jedno, BSI (německý Spolkový úřad pro informační bezpečnost) doporučuje webový server dočasně odpojit od sítě.
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.
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 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 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.