Zabezpečení Apache s mod_php

Stručně: U Apache s mod_php běží PHP přímo ve webovém serveru. Tým PHP hodnotí riziko PHP2Shell právě v tomto provozním režimu jako nejvyšší, protože byl předveden exploit dřív, než se vůbec spustí kód aplikace. Záplatujte okamžitě, Apache úplně restartujte a poté naplánujte přechod na PHP-FPM.

Co je mod_php a proč na něm nyní záleží

U mod_php načítá Apache PHP jako modul do každého vlastního pracovního procesu. Každý požadavek na soubor PHP se provádí přímo v tomto procesu. To byl dlouho standard a je snadné to nastavit. Znamená to ale také: všechny weby na serveru běží pod stejným uživatelem a PHP sdílí proces s webovým serverem.

PHP2Shell zahrnuje zranitelnosti CVE-2026-109618 a CVE-2026-109619, obě s CVSS v4.0 9,2. U druhé může vnitřní stav požadavku po uvolnění paměti přetrvat a být využit pozdějším požadavkem ve stejném procesu. Pro mod_php tým PHP zjistil nejvyšší riziko. Souvislosti a zařazení najdete na stránce Proč nese mod_php nejvyšší riziko.

Rozpoznat Apache mod_php a zkontrolovat verzi

Nejdřív zkontrolujte, zda váš Apache mod_php vůbec používá. Následující příkazy jen čtou. Názvy příkazů a balíčků se liší podle distribuce a jsou příklady.

# Debian/Ubuntu: načtené moduly
apache2ctl -M 2>/dev/null | grep -i php

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

# Který MPM je aktivní? mod_php vyžaduje prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Stav balíčku modulu (příklady)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Pokud se objeví modul jako php_module, běží mod_php. Samotná zobrazená verze PHP není dokladem záplaty, protože distribuce opravy často nasazují jako backport. Opravené verze projektu PHP jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35. U balíčků distribucí rozhoduje changelog s čísly CVE.

Záplatovat a úplně restartovat Apache

Aktualizaci nasaďte přes správu balíčků. Protože PHP sídlí v procesu Apache, musí se poté restartovat celá služba. Opětovné načtení konfigurace zde není bezpečná cesta.

# Debian/Ubuntu
systemctl restart apache2

# Rodina RHEL
systemctl restart httpd

# Kontrola: čas spuštění všech procesů Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Všechny procesy Apache musí vykazovat čas spuštění po aktualizaci. Pokud na stejném serveru běží navíc PHP-FPM nebo php-cgi, restartujte i tyto služby.

Přechodná opatření v konfiguraci Apache

php.net uvádí přechodná opatření, která riziko snižují, ale neposkytují úplnou ochranu. U mod_php nastavíte hodnoty pomocí php_admin_value, resp. php_admin_flag v konfiguraci Apache, aby je .htaccess ani aplikace nemohly přepsat.

# Příklad: v konfiguraci VirtualHost nebo v konfiguraci celého serveru
<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>

S funkcí nahrávání souborů uvádí php.net post_max_size = 32M, upload_max_filesize níže. Na PHP 8.5 přibývá fatal_error_backtraces=0. Upozornění k memory_limit=-1 provádějte jen spolu s limitem paměti pro službu přes cgroups, například pomocí MemoryMax v doplňku systemd, nikoli přes RLIMIT_AS nebo RLIMIT_DATA. Poté Apache úplně restartujte. Všechna opatření v přehledu: Okamžitá opatření bez záplaty.

Cesta pryč od mod_php

Po akutní záplatě se vyplatí přechod na PHP-FPM. PHP přitom běží ve vlastních procesech oddělených od webového serveru. Každý web může dostat vlastní pool s vlastním uživatelem, hranice lze nastavit pro každý pool a restarty se týkají jen PHP. Apache připojí PHP-FPM přes mod_proxy_fcgi a místo prefork pak může použít modernější MPM, například event.

Změnu naplánujte v testovacím prostředí: založit pooly pro každý web, přizpůsobit oprávnění k souborům novým uživatelům, převést záznamy .htaccess s php_value do nastavení poolu, provést zátěžové testy. Jak vypadá čistá architektura, ukazuje stránka Zabezpečení Nginx s PHP-FPM; zásady platí stejně i pro Apache s PHP-FPM.

Bez ohledu na provozní režim platí: záplata neodstraní již zavlečený škodlivý software. Uchovejte logy od 20. 10. 2026 a zkontrolujte server, zda nenese stopy.

Při hledání stop na serverech s mod_php stojí za pohled na společného uživatele. Protože všechny weby běží pod uživatelem Apache, například www-data nebo apache, může útočník, který převzal jeden web, zpravidla číst a měnit i soubory ostatních. Nekontrolujte proto jen web, který vám připadá nápadný, ale všechny document rooty na serveru. Dávejte pozor zejména na soubory PHP s nedávným datem změny v adresářích pro nahrávání a cache, na programový kód patřící uživateli Apache a na neznámé záznamy v crontabu tohoto uživatele. Pokud něco najdete, nejdříve zajistěte stav a nemažte předčasně, aby zůstala příčina později dohledatelná.

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

• Zkontrolujeme provozní režim, MPM a stav balíčků a posoudíme, zda je váš server skutečně zazáplatován.
• Prostřednictvím služby záplatování PHP nasadíme aktualizaci, Apache úplně restartujeme a doložíme to.
• Do záplaty nastavíme přechodná opatření tak, aby je nešlo přepsat, a omezíme paměť na úrovni služby.
• V rámci zpevnění serveru naplánujeme a otestujeme přechod na PHP-FPM s oddělenými pooly.

Časté dotazy

Zdroje

• php.net: bezpečnostní oznámení
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets