# Zabezpečenie Apache s mod_php

> Apache mod_php po PHP2Shell: rozpoznajte režim prevádzky, zaplátajte modul PHP, úplne reštartujte Apache a čisto pripravte prechod na PHP-FPM.

Zdroj: https://phpsos.de/sk/server/apache-mod-php/  
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:** Pri Apache s mod_php beží PHP priamo vo webovom serveri. Tím PHP hodnotí riziko PHP2Shell práve v tomto režime prevádzky najvyššie, pretože exploit bol predvedený ešte predtým, než sa vôbec spustí kód aplikácie. Zaplátajte okamžite, úplne reštartujte Apache a potom naplánujte prechod na PHP-FPM.

## Čo je mod_php a prečo na ňom teraz záleží

Pri mod_php Apache načíta PHP ako modul do každého vlastného pracovného procesu. Každý požiadavok na súbor PHP sa vykoná priamo v tomto procese. Dlho to bol štandard a jednoducho sa to nastavuje. Znamená to však aj: všetky weby na serveri bežia pod tým istým používateľom a PHP zdieľa proces s webovým serverom.

PHP2Shell zahŕňa zraniteľnosti CVE-2026-109618 a CVE-2026-109619, obe s CVSS v4.0 9.2. Pri druhej môže vnútorný stav požiadavky po uvoľnení pamäte zostať zachovaný a použiť ho neskorší požiadavok v tom istom procese. Pre mod_php tím PHP stanovil najvyššie riziko. Súvislosti a zaradenie nájdete na stránke [Prečo mod_php nesie najvyššie riziko](https://phpsos.de/sk/php2shell/mod-php-risiko/).

## Rozpoznanie Apache mod_php a kontrola verzie

Najprv skontrolujte, či váš Apache mod_php vôbec používa. Nasledujúce príkazy iba čítajú. Názvy príkazov a balíkov sa líšia podľa distribúcie a sú príkladmi.

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

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

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

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

Ak sa objaví modul ako `php_module`, beží mod_php. Samotná zobrazená verzia PHP nie je dôkazom záplaty, pretože distribúcie často nasadzujú opravy ako backport. Opravené verzie projektu PHP sú 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Pri balíkoch distribúcie sa počíta changelog s číslami CVE.

## Zaplátajte a úplne reštartujte Apache

Aktualizáciu nasaďte cez správcu balíkov. Keďže PHP sedí v procese Apache, musí sa potom reštartovať celá služba. Opätovné načítanie konfigurácie tu nie je bezpečnou cestou.

```bash
# Debian/Ubuntu
systemctl restart apache2

# Rodina RHEL
systemctl restart httpd

# Kontrola: čas spustenia všetkých procesov Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Všetky procesy Apache musia ukazovať čas spustenia po aktualizácii. Ak na tom istom serveri beží navyše PHP-FPM alebo php-cgi, reštartujte aj tieto služby.

> **Konajte hneď:**
> Ak pre vašu verziu PHP ešte nie je záplata k dispozícii, BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča webový server dočasne odpojiť od siete. Pri mod_php to váži obzvlášť ťažko, pretože útok môže zasiahnuť pred kódom aplikácie.

## Prechodné opatrenia v konfigurácii Apache

php.net uvádza prechodné opatrenia, ktoré znižujú riziko, ale neposkytujú úplnú ochranu. Pri mod_php nastavte hodnoty pomocou `php_admin_value`, resp. `php_admin_flag` v konfigurácii Apache, aby ich `.htaccess` a aplikácie nemohli prepísať.

```apache
# Príklad: v konfigurácii VirtualHost alebo celoserverovo
<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 funkciou nahrávania php.net uvádza `post_max_size = 32M`, pričom `upload_max_filesize` je nižšie. Pri PHP 8.5 pribúda `fatal_error_backtraces=0`. Upozornenie k `memory_limit=-1` uplatnite iba spolu s obmedzením pamäte pre službu cez cgroups, napríklad pomocou `MemoryMax` v doplnku systemd, nie cez `RLIMIT_AS` alebo `RLIMIT_DATA`. Potom Apache úplne reštartujte. Všetky opatrenia v prehľade: [Okamžité opatrenia bez záplaty](https://phpsos.de/sk/php2shell/sofortmassnahmen-ohne-patch/).

## Cesta preč od mod_php

Po akútnej záplate sa oplatí prechod na PHP-FPM. PHP tam beží vo vlastných procesoch, oddelene od webového servera. Každý web môže dostať vlastný pool s vlastným používateľom, limity sa dajú nastaviť pre každý pool a reštarty sa týkajú iba PHP. Apache pripojí PHP-FPM cez `mod_proxy_fcgi` a potom môže namiesto prefork používať modernejší MPM, ako je event.

Prechod naplánujte v testovacom prostredí: vytvoriť pooly pre každý web, prispôsobiť práva k súborom novým používateľom, záznamy `.htaccess` s `php_value` previesť do nastavení poolu, urobiť záťažové testy. Ako vyzerá čisté usporiadanie, ukazuje stránka [Zabezpečenie Nginx s PHP-FPM](https://phpsos.de/sk/server/nginx-php-fpm/); zásady platia rovnako pre Apache s PHP-FPM.

Bez ohľadu na režim prevádzky platí: Záplata neodstráni už zavlečený škodlivý softvér. Uchovajte logy od 20. 10. 2026 a skontrolujte server na stopy.

Pri hľadaní stôp na serveroch s mod_php sa oplatí pozrieť sa na spoločného používateľa. Keďže všetky weby bežia pod používateľom Apache, napríklad `www-data` alebo `apache`, môže útočník, ktorý prevzal jeden web, spravidla čítať a meniť aj súbory ostatných. Preto nekontrolujte iba web, ktorý sa vám zdá nápadný, ale všetky document root na serveri. Dávajte pozor najmä na súbory PHP s nedávnym dátumom zmeny v adresároch na nahrávanie a v cache, na programový kód patriaci používateľovi Apache a na neznáme záznamy v crontab tohto používateľa. Ak niečo nájdete, najprv zabezpečte stav a nemažte unáhlene, aby zostala príčina neskôr dohľadateľná.

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

- Skontrolujeme režim prevádzky, MPM a stav balíkov a posúdime, či je váš server skutočne zaplátaný.
- Cez [službu záplatovania PHP](https://phpsos.de/sk/leistungen/php-patch-service/) nasadíme aktualizáciu, úplne reštartujeme Apache a zdokumentujeme dôkaz.
- Do vydania záplaty nastavíme prechodné opatrenia tak, aby sa nedali prepísať, a obmedzíme pamäť na úrovni služby.
- V rámci [spevnenia servera (hardening)](https://phpsos.de/sk/leistungen/server-haertung/) naplánujeme a otestujeme prechod na PHP-FPM so samostatnými poolmi.


## Časté otázky

**Ako poznám, že môj server používa mod_php?**  
Ak má Apache načítaný modul PHP, objaví sa v zozname modulov ako php_module alebo s číslom verzie v názve. Výstup phpinfo navyše pri Server API ukazuje záznam Apache 2.0 Handler. Takýto testovací súbor hneď zmažte.

**Prečo je mod_php pri PHP2Shell obzvlášť kritické?**  
Podľa tímu PHP je tam riziko najvyššie; exploit bol predvedený ešte predtým, než sa vôbec spustí kód aplikácie. Preto nechráni ani dobre udržiavaná aplikácia. Rýchla aktualizácia má preto najvyššiu prioritu.

**Stačí po aktualizácii reload Apache?**  
Bezpečný je úplný reštart služby, pretože PHP sedí ako modul v procesoch Apache. Potom skontrolujte čas spustenia všetkých procesov Apache. Nesmú zostať procesy staršie než aktualizácia.

**Je prechod na PHP-FPM náročný?**  
Väčšinou sa dá dobre naplánovať: nainštalovať PHP-FPM, vytvoriť pooly, prepnúť Apache na proxy_fcgi a zmeniť prefork na iný MPM. Vopred to otestujte v kópii prostredia.

## Zdroje

- [php.net: bezpečnostné hlásenia](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/)