# Zabezpečení Apache s mod_php

> Apache mod_php po PHP2Shell: rozpoznejte provozní režim, zazáplatujte modul PHP, úplně restartujte Apache a řádně připravte přechod na PHP-FPM.

Zdroj: https://phpsos.de/cs/server/apache-mod-php/  
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ě:** 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](https://phpsos.de/cs/php2shell/mod-php-risiko/).

## 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.

```bash
# 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.

```bash
# 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.

> **Jednejte ihned:**
> Pokud pro vaši verzi PHP zatím záplata není k dispozici, BSI (německý Spolkový úřad pro informační bezpečnost) doporučuje webový server dočasně odpojit od sítě. U mod_php to váží obzvlášť, protože útok může zabrat dřív než kód aplikace.

## 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.

```apache
# 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](https://phpsos.de/cs/php2shell/sofortmassnahmen-ohne-patch/).

## 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](https://phpsos.de/cs/server/nginx-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](https://phpsos.de/cs/leistungen/php-patch-service/) 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](https://phpsos.de/cs/leistungen/server-haertung/) naplánujeme a otestujeme přechod na PHP-FPM s oddělenými pooly.


## Časté dotazy

**Jak poznám, zda můj server používá mod_php?**  
Pokud má Apache načtený modul PHP, objeví se v seznamu modulů jako php_module nebo s číslem verze v názvu. Výstup phpinfo navíc u Server API ukazuje položku Apache 2.0 Handler. Takový testovací soubor ihned zase smažte.

**Proč je mod_php u PHP2Shell obzvlášť kritický?**  
Podle týmu PHP je tam riziko nejvyšší; exploit byl předveden dřív, než se vůbec spustí kód aplikace. Nechrání tedy ani dobře udržovaná aplikace. Rychlá aktualizace má proto nejvyšší prioritu.

**Stačí po aktualizaci reload Apache?**  
Bezpečný je úplný restart služby, protože PHP je jako modul součástí procesů Apache. Poté zkontrolujte čas spuštění všech procesů Apache. Žádné procesy starší než aktualizace nesmějí zůstat.

**Je přechod na PHP-FPM náročný?**  
Většinou je dobře naplánovatelný: nainstalovat PHP-FPM, založit pooly, přepnout Apache na proxy_fcgi a přejít z prefork na jiný MPM. Vyzkoušejte to předem v kopii prostředí.

## Zdroje

- [php.net: bezpečnostní oznámení](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/)
