# Prečo nesie mod_php najvyššie riziko

> Prečo tím PHP hodnotí riziko PHP2Shell pri Apache s mod_php ako najvyššie, ako mod_php rozpoznať a čo teraz záplatovať a prestaviť.

Zdroj: https://phpsos.de/sk/php2shell/mod-php-risiko/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** PHP2Shell sa týka všetkých bežných spôsobov prevádzky, ale pri Apache s mod_php hodnotí tím PHP riziko ako najvyššie. Tam bol ukázaný exploit ešte predtým, než sa vôbec spustí kód aplikácie. Kto prevádzkuje mod_php, mal by najprv aktualizovať PHP a úplne reštartovať Apache.

## Čo je mod_php?

Pri mod_php je PHP modulom vnútri webového servera Apache. Každý proces Apache obsahuje úplný interpreter PHP a spúšťa kód PHP priamo. Tento spôsob prevádzky bol dlho štandardom a dodnes je rozšírený na starších serveroch, v mnohých distribučných balíkoch a v niektorých obrazoch Docker.

Alternatívou je PHP-FPM: tam beží PHP ako samostatná služba s vlastnými procesmi a Apache alebo Nginx požiadavky iba odovzdáva ďalej. Obe varianty sú PHP2Shell dotknuté, rovnako ako php-cgi, FrankenPHP a LiteSpeed.

Typické prostredia s mod_php sú starší root servery, ktoré roky bežia nezmenené, štandardné inštalácie Apache z distribučných balíkov a obrazy Docker s Apache a PHP v jednom kontajneri. Kto nevie isto, ktorý spôsob prevádzky jeho server používa, mal by to preveriť namiesto toho, aby to predpokladal.

## Prečo sa zraniteľnosť mod_php považuje za obzvlášť rizikovú?

Tím PHP podal k PHP2Shell jasné posúdenie: pri mod_php je riziko najvyššie. Zdôvodnenie: tam bol ukázaný exploit, ktorý zaberie ešte predtým, než sa vôbec spustí kód aplikácie.

Pre prevádzkovateľov z toho vyplýva nepríjemný dôsledok. Mnohé ochranné opatrenia sedia v aplikácii: bezpečnostné doplnky vo WordPresse, firewallové moduly v obchodoch, kontroly vo vlastnom kóde. Všetky sú kódom aplikácie. Ak sa zneužitie odohrá predtým, prichádzajú neskoro.

K tomu pribúda úzke prepojenie: pri mod_php zdieľa PHP proces s Apache. Čo PHP kompromituje, beží s právami webového servera a v jeho pamäti. Pri PHP-FPM sa naopak dajú pooly oddeliť s vlastnými používateľmi pre každý web, čo môže následky vlámania obmedziť.

Pre určenie priorít to znamená: ak prevádzkujete viac serverov, tie s mod_php prídu na rad ako prvé a pri nich je následná kontrola stôp obzvlášť dôležitá.

Čo nevieme: koľko z celosvetovo napočítaných 22,6 milióna exponovaných, potenciálne zraniteľných inštancií používa mod_php. Spoľahlivé čísla k tomu nie sú zverejnené.

## Používa môj server mod_php?

Nasledujúce príkazy sú čisto čítacie. Názvy služieb a príkazov sa líšia podľa distribúcie: Debian a Ubuntu používajú `apache2`, rodina RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # napr. php_module alebo 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íka modulu
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # rodina RHEL
```

Ak sa neobjaví žiadny modul PHP, Apache pravdepodobne používa PHP-FPM cez `proxy_fcgi`. Potom platia upozornenia zo stránky [Zabezpečenie Nginx s PHP-FPM](https://phpsos.de/sk/server/nginx-php-fpm/) obdobne.

## Čo by mali prevádzkovatelia mod_php urobiť teraz

1. **Aktualizovať modul PHP** na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35 alebo potvrdený backport vašej distribúcie.
2. **Apache úplne reštartovať,** nielen znova načítať. Pri mod_php sedí starý kód PHP v každom procese Apache.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # rodina RHEL
ps -o pid,lstart,cmd -C apache2    # skontrolovať čas spustenia, v RHEL: -C httpd
```

3. **Nastaviť prechodné opatrenia, ak aktualizácia ešte nejde.** php.net uvádza okrem iného pevné hranice, ktoré aplikácie nemôžu prepísať:

```apache
# Konfigurácia servera alebo 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
```

S `memory_limit=-1` patrí k tomu hranica pamäte cez cgroup, nie cez `RLIMIT_AS` alebo `RLIMIT_DATA`. Tieto opatrenia nie sú úplnou ochranou; podrobnosti nájdete na stránke [Okamžité opatrenia, ak ešte nemôžete záplatovať](https://phpsos.de/sk/php2shell/sofortmassnahmen-ohne-patch/). Ak nejde hneď ani jedno, BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča webový server dočasne odpojiť od siete.

> **Konajte hneď:**
> Ak váš Apache s mod_php bežal medzi 17. októbrom a záplatou nechránene na internete, zabezpečte logy od 20. októbra a nechajte server skontrolovať z hľadiska stôp. Samotná záplata nedokazuje, že sa nič nestalo.

## V strednodobom horizonte: preč od mod_php

Po záplate sa oplatí pozrieť na architektúru. Prechod na PHP-FPM s Apache `mpm_event` a `proxy_fcgi` alebo s Nginx oddelí PHP od webového servera, umožní vlastné pooly a používateľov pre každý web a uľahčí reštarty i zmeny verzií. PHP2Shell neuzavrie, ale zmenšuje plochu útoku budúcich zraniteľností.

Prechod potrebuje plánovanie. Nastavenia, ktoré sa doteraz zadávali cez `php_value` v `.htaccess`, pod PHP-FPM nezaberajú a musia sa presunúť do poolu. Používatelia a práva sa menia, adresáre na nahrávanie a cache môžu potrebovať nové oprávnenia. V testovacom prostredí je to dobre zvládnuteľné, v živej prevádzke pod časovým tlakom nie. Upozornenia k prechodu nájdete na stránke [Zabezpečenie Apache s mod_php](https://phpsos.de/sk/server/apache-mod-php/).

## Ako konkrétne pomáha PHP SOS?

- **Rozpoznať:** Preveríme, ktoré servery používajú mod_php a z ktorého zdroja balíkov modul pochádza.
- **Záplatovať a reštartovať:** Cez [službu záplatovania PHP](https://phpsos.de/sk/leistungen/php-patch-service/) nasadíme aktualizáciu a skontrolujeme, že už nebeží žiadny starý proces Apache.
- **Zabezpečiť prechod:** Kde je aktualizácia zablokovaná, nastavíme opatrenia z php.net v konfigurácii servera.
- **Prestaviť:** V rámci [spevnenia zabezpečenia servera](https://phpsos.de/sk/leistungen/server-haertung/) naplánujeme a otestujeme prechod na PHP-FPM s oddelenými poolmi.


## Časté otázky

**Podľa čoho spoznám, či môj Apache používa mod_php?**  
Pomocou apachectl -M alebo httpd -M uvidíte načítané moduly. Ak je tam modul ako php_module alebo php8_module, PHP beží priamo v Apache. Pod Debianom a Ubuntu zobrazí aj a2query -m, či je aktívny modul php.

**Chráni ma pri mod_php bezpečnostný doplnok vo WordPresse?**  
Pri tejto zraniteľnosti nie. Podľa tímu PHP bol pri mod_php ukázaný exploit ešte predtým, než sa vôbec spustí kód aplikácie. Doplnok je kód aplikácie a prichádza teda neskoro. Ochranu poskytuje iba aktualizácia PHP s reštartom Apache.

**Mal by som teraz z mod_php prejsť na PHP-FPM?**  
Najprv záplatovať, potom prestaviť. Prechod na PHP-FPM je pre väčšinu nastavení v strednodobom horizonte zmysluplný, pretože PHP potom beží oddelene od webového servera. PHP2Shell však neuzavrie, pretože PHP-FPM je tiež dotknuté.

## Zdroje

- [php.net: bezpečnostné hlásenia](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Spolkový úrad pre informačnú bezpečnosť](https://www.bsi.bund.de/)