Zabezpečenie Apache s mod_php

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.

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.

# 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.

# 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.

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ť.

# 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.

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; 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 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) naplánujeme a otestujeme prechod na PHP-FPM so samostatnými poolmi.

Časté otázky

Zdroje

• php.net: bezpečnostné hlásenia
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets