Na kratko: PHP2Shell zadeva vse običajne načine delovanja, vendar ekipa PHP pri Apacheu z mod_php tveganje ocenjuje kot najvišje. Tam je bil exploit prikazan, še preden se sploh izvede koda aplikacije. Kdor upravlja mod_php, naj najprej posodobi PHP in popolnoma znova zažene Apache.
Kaj je mod_php?
Pri mod_php je PHP modul znotraj spletnega strežnika Apache. Vsak proces Apache vsebuje poln interpreter PHP in kodo PHP izvaja neposredno. Ta način delovanja je bil dolgo standard in je na starejših strežnikih, v številnih paketih distribucij in v nekaterih slikah Docker še danes razširjen.
Alternativa je PHP-FPM: tam PHP teče kot lastna storitev z lastnimi procesi, Apache ali Nginx pa zahteve samo posreduje naprej. Obe različici sta prizadeti zaradi PHP2Shell, prav tako php-cgi, FrankenPHP in LiteSpeed.
Tipična okolja z mod_php so starejši root strežniki, ki teče leta nespremenjeno, standardne namestitve Apacheja iz paketov distribucij in slike Docker z Apachejem in PHP v enem containerju. Kdor ne ve zanesljivo, kateri način delovanja uporablja njegov strežnik, naj to preveri, namesto da bi domneval.
Zakaj ranljivost mod_php velja za posebej tvegano?
Ekipa PHP je za PHP2Shell podala jasno oceno: pri mod_php je tveganje najvišje. Utemeljitev: tam je bil prikazan exploit, ki deluje, še preden se sploh izvede koda aplikacije.
Za upravljavce ima to neprijetno posledico. Številni zaščitni ukrepi so v aplikaciji: varnostni vtičniki v WordPressu, požarni moduli v trgovinah, preverjanja v lastni kodi. Vsi so koda aplikacije. Če se izkoriščanje zgodi pred njo, pridejo prepozno.
Doda se tesna povezanost: pri mod_php si PHP deli proces z Apachejem. Kar PHP ogrozi, teče s pravicami spletnega strežnika in v njegovem pomnilniku. Pri PHP-FPM je pool mogoče ločiti z lastnimi uporabniki za vsako spletno stran, kar lahko omeji posledice vdora.
Za prednostno razvrščanje to pomeni: če upravljate več strežnikov, so tisti z mod_php na vrsti prvi, pri njih pa je naknadni pregled sledi še posebej pomemben.
Česa ne vemo: koliko od po svetu naštetih 22,6 milijona izpostavljenih, potencialno ranljivih instanc uporablja mod_php. Zanesljivih številk o tem ni objavljenih.
Ali moj strežnik uporablja mod_php?
Naslednji ukazi so izključno bralni. Imena storitev in ukazov se po distribuciji razlikujejo: Debian in Ubuntu uporabljata apache2, družina RHEL httpd.
apachectl -M 2>/dev/null | grep -i php # npr. php_module ali 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, stanje paketa modula
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # družina RHEL
Če noben modul PHP ne nastopi, Apache verjetno uporablja PHP-FPM prek proxy_fcgi. Takrat smiselno veljajo napotki na strani Zavarovanje Nginxa s PHP-FPM.
Kaj naj upravljavci mod_php zdaj storijo
- Posodobiti modul PHP na 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 ali potrjen backport vaše distribucije.
- Popolnoma znova zagnati Apache, ne samo ponovno naložiti. Pri mod_php stara koda PHP tiči v vsakem procesu Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # družina RHEL
ps -o pid,lstart,cmd -C apache2 # preveriti čas zagona, v RHEL: -C httpd
- Uvesti vmesne ukrepe, če posodobitev še ni mogoča. php.net med drugim navaja trdne meje, ki jih aplikacije ne morejo prepisati:
# Konfiguracija strežnika ali VirtualHost, ne .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
Pri memory_limit=-1 sodi zraven omejitev pomnilnika prek cgroup, ne prek RLIMIT_AS ali RLIMIT_DATA. Ti ukrepi niso popolna zaščita; podrobnosti so na strani Takojšnji ukrepi, če še ne morete popraviti. Če ni mogoče nobeno od obojega takoj, BSI priporoča, da se spletni strežnik začasno odklopi z omrežja.
Če je vaš Apache z mod_php med 17. oktobrom in popravkom nezaščiten tekel na internetu, zavarujte dnevnike od 20. oktobra dalje in strežnik dajte pregledati glede sledi. Sam popravek ne dokazuje, da se ni nič zgodilo.
Srednjeročno: stran od mod_php
Po popravku se splača pogledati arhitekturo. Prehod na PHP-FPM z Apachejem mpm_event in proxy_fcgi ali z Nginxom loči PHP od spletnega strežnika, omogoča lastne poole in uporabnike za vsako spletno stran ter poenostavi ponovne zagone in zamenjave različic. PHP2Shell ne zapre, a zmanjša napadalno površino prihodnjih ranljivosti.
Preklop zahteva načrtovanje. Nastavitve, ki so bile doslej določene s php_value v .htaccess, pod PHP-FPM ne delujejo več in se morajo preseliti v pool. Uporabniki in pravice se spremenijo, mape za nalaganje in predpomnilnik morda potrebujejo nove dovolitve. V testnem okolju je to dobro obvladljivo, v živem obratovanju pod časovnim pritiskom pa ne. Napotke za preklop najdete na strani Zavarovanje Apacheja z mod_php.
Kako konkretno pomaga PHP SOS?
- Prepoznati: preverimo, kateri strežniki uporabljajo mod_php in iz katerega paketnega vira izvira modul.
- Popraviti in znova zagnati: prek storitve popravljanja PHP namestimo posodobitev in kontroliramo, da noben star proces Apache ne teče več.
- Zavarovati prehod: kjer je posodobitev blokirana, ukrepe php.net nastavimo v konfiguraciji strežnika.
- Preklopiti: v okviru utrjevanja strežnika načrtujemo in preizkusimo prehod na PHP-FPM z ločenimi pooli.
Pogosta vprašanja
Po čem prepoznam, ali moj Apache uporablja mod_php?
Z apachectl -M ali httpd -M vidite naložene module. Če je tam modul, kot je php_module ali php8_module, PHP teče neposredno v Apacheu. V Debianu in Ubuntuju tudi a2query -m pokaže, ali je modul php aktiven.
Ali me pri mod_php varuje varnostni vtičnik v WordPressu?
Pri tej ranljivosti ne. Po navedbah ekipe PHP je bil pri mod_php exploit prikazan, še preden se sploh izvede koda aplikacije. Vtičnik je koda aplikacije in zato pride prepozno. Zaščito nudi samo posodobitev PHP s ponovnim zagonom Apacheja.
Ali naj zdaj preklopim z mod_php na PHP-FPM?
Najprej popravite, nato preklopite. Prehod na PHP-FPM je za večino postavitev srednjeročno smiseln, ker PHP potem teče ločeno od spletnega strežnika. PHP2Shell pa ne zapre, saj je PHP-FPM prav tako prizadet.