Pe scurt: De PHP2Shell sunt afectate toate modurile de operare uzuale, dar la Apache cu mod_php echipa PHP evaluează riscul ca fiind cel mai ridicat. Acolo a fost demonstrat un exploit înainte ca vreun cod de aplicație să ruleze. Cine operează mod_php ar trebui să actualizeze mai întâi PHP și să repornească Apache complet.
Ce este mod_php?
La mod_php, PHP este un modul în interiorul serverului web Apache. Fiecare proces Apache conține un interpretor PHP complet și execută direct codul PHP. Acest mod de operare a fost mult timp standardul și este răspândit și astăzi pe servere mai vechi, în multe pachete de distribuție și în unele imagini Docker.
Alternativa este PHP-FPM: acolo PHP rulează ca serviciu separat, cu procese proprii, iar Apache sau Nginx doar transmite cererile mai departe. Ambele variante sunt afectate de PHP2Shell, la fel ca php-cgi, FrankenPHP și LiteSpeed.
Medii tipice cu mod_php sunt serverele root mai vechi, care rulează neschimbate de ani de zile, instalările standard Apache din pachete de distribuție și imaginile Docker cu Apache și PHP într-un singur container. Cine nu știe sigur ce mod de operare folosește serverul său ar trebui să verifice, nu să presupună.
De ce este vulnerabilitatea mod_php considerată deosebit de riscantă?
Echipa PHP a dat pentru PHP2Shell o apreciere clară: la mod_php riscul este cel mai ridicat. Motivare: acolo a fost demonstrat un exploit care acționează înainte ca vreun cod de aplicație să ruleze.
Pentru operatori are o consecință neplăcută. Multe măsuri de protecție se află în aplicație: plugin-uri de securitate în WordPress, module firewall în magazine, verificări în codul propriu. Toate sunt cod de aplicație. Dacă exploatarea are loc înaintea lor, ele vin prea târziu.
La acestea se adaugă strânsa legătură: la mod_php, PHP împarte procesul cu Apache. Ce compromite PHP rulează cu drepturile serverului web și în memoria acestuia. La PHP-FPM, pool-urile pot fi în schimb separate, cu utilizatori proprii pentru fiecare site, ceea ce poate limita consecințele unei intruziuni.
Pentru stabilirea priorităților înseamnă: dacă operați mai multe servere, cele cu mod_php vin primele la rând, iar la ele o verificare ulterioară a urmelor este deosebit de importantă.
Ce nu știm: câte dintre cele 22,6 milioane de instanțe expuse, potențial vulnerabile, numărate la nivel mondial folosesc mod_php. Cifre solide în acest sens nu au fost publicate.
Serverul meu folosește mod_php?
Comenzile următoare sunt strict de citire. Numele serviciilor și ale comenzilor diferă în funcție de distribuție: Debian și Ubuntu folosesc apache2, familia RHEL httpd.
apachectl -M 2>/dev/null | grep -i php # de ex. php_module sau 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, starea pachetului modulului
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # familia RHEL
Dacă nu apare niciun modul PHP, Apache folosește probabil PHP-FPM prin proxy_fcgi. Atunci indicațiile de la Cum securizați Nginx cu PHP-FPM se aplică prin analogie.
Ce ar trebui să facă acum operatorii mod_php
- Actualizați modulul PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 ori la un backport confirmat al distribuției dumneavoastră.
- Reporniți Apache complet, nu doar reîncărcați. La mod_php, vechiul cod PHP se află în fiecare proces Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # familia RHEL
ps -o pid,lstart,cmd -C apache2 # verificați ora de pornire, pe RHEL: -C httpd
- Setați măsuri provizorii dacă actualizarea nu este încă posibilă. php.net menționează, printre altele, limite fixe pe care aplicațiile nu le pot suprascrie:
# configurația serverului sau VirtualHost, nu .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
Cu memory_limit=-1 trebuie să existe și o limită de memorie prin cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA. Aceste măsuri nu sunt o protecție completă; detaliile le găsiți la Măsuri imediate dacă nu puteți încă aplica patchul. Dacă niciuna nu este posibilă imediat, BSI recomandă scoaterea temporară din rețea a serverului web.
Dacă Apache-ul dumneavoastră cu mod_php a fost expus în internet fără protecție între 17 octombrie și patch, salvați logurile începând cu 20 octombrie și puneți serverul la verificare pentru urme. Patchul singur nu dovedește că nu s-a întâmplat nimic.
Pe termen mediu: renunțarea la mod_php
După patch merită o privire asupra arhitecturii. Trecerea la PHP-FPM cu Apache mpm_event și proxy_fcgi sau cu Nginx separă PHP de serverul web, permite pool-uri și utilizatori proprii pentru fiecare site și face mai simple repornirile și schimbările de versiune. Nu închide PHP2Shell, dar reduce suprafața de atac a vulnerabilităților viitoare.
Trecerea necesită planificare. Setările care erau stabilite până acum prin php_value în .htaccess nu mai au efect sub PHP-FPM și trebuie mutate în pool. Utilizatorii și drepturile se schimbă, dosarele de încărcare și de cache pot necesita permisiuni noi. Într-un mediu de test este bine de stăpânit, în funcționarea curentă, sub presiunea timpului, nu. Indicații pentru trecere găsiți la Cum securizați Apache cu mod_php.
Cum ajută PHP SOS concret?
- Recunoaștere: Verificăm care servere folosesc mod_php și din ce sursă de pachete provine modulul.
- Patch și repornire: Prin serviciul de patch PHP aplicăm actualizarea și controlăm ca niciun proces Apache vechi să nu mai ruleze.
- Protejarea tranziției: Acolo unde actualizarea este blocată, setăm măsurile de la php.net în configurația serverului.
- Trecerea: În cadrul securizării serverului planificăm și testăm schimbarea la PHP-FPM cu pool-uri separate.
Întrebări frecvente
Cum recunosc dacă Apache-ul meu folosește mod_php?
Cu apachectl -M sau httpd -M vedeți modulele încărcate. Dacă apare un modul precum php_module sau php8_module, PHP rulează direct în Apache. Pe Debian și Ubuntu, a2query -m arată de asemenea dacă un modul php este activ.
Mă protejează un plugin de securitate din WordPress la mod_php?
La această vulnerabilitate, nu. Potrivit echipei PHP, la mod_php a fost demonstrat un exploit înainte ca vreun cod de aplicație să ruleze. Un plugin este cod de aplicație și vine, așadar, prea târziu. Protecție oferă doar actualizarea PHP cu repornirea Apache.
Ar trebui să trec acum de la mod_php la PHP-FPM?
Mai întâi patchul, apoi trecerea. Schimbarea la PHP-FPM este pe termen mediu utilă pentru majoritatea configurațiilor, deoarece PHP rulează atunci separat de serverul web. Ea nu închide însă PHP2Shell, pentru că și PHP-FPM este afectat.