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.
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 obdobne.
Čo by mali prevádzkovatelia mod_php urobiť teraz
- Aktualizovať modul PHP na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35 alebo potvrdený backport vašej distribúcie.
- Apache úplne reštartovať, nielen znova načítať. Pri mod_php sedí starý kód PHP v každom procese Apache.
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
- 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ť:
# 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ť. Ak nejde hneď ani jedno, BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča webový server dočasne odpojiť od siete.
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.
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 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 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é.