PHP2Shell: ce reduce cu adevărat riscul înainte de patch-ul PHP

PHP lansează remedieri pentru două vulnerabilități critice de execuție de cod de la distanță (RCE), denumite generic PHP2Shell, la ora 14:00 UTC, pe 21 octombrie 2026. Proiectul le evaluează cu 9,2 din 10 și nu a publicat nicio soluție temporară proprie. Modificarea de configurare răspândită pe rețelele sociale ca „fix rapid” nu este, potrivit celor mai apropiați de problemă, o remediere.

Ce s-a întâmplat

Detaliile sunt intenționat puține. PHP nu a precizat ce versiuni sunt afectate, ce componentă este implicată sau dacă vreo setare de configurare schimbă riscul. Detaliile complete și versiunile corectate vin odată cu lansarea. Până atunci, nimeni din afara grupului care a descoperit vulnerabilitățile nu poate verifica în mod fiabil dacă o anumită apărare funcționează.

Pe 21 octombrie dimineața, o firmă de securitate din Tokyo a sugerat dezactivarea Session Upload Progress (session.upload_progress.enabled=0) ca posibilă măsură de atenuare, precizând însă că nu poate garanta că problema este rezolvată complet. Câteva ore mai târziu, aceeași firmă a revenit: setarea singură nu este o remediere completă și sunt așteptate metode de ocolire. Contribuitori din echipa PHP au fost și mai direcți: singura atenuare reală este actualizarea, iar setările ini nu vă vor proteja.

Chiar și premisa este contestată. Faptul că eroarea s-ar afla în Session Upload Progress nu a fost confirmat de PHP, iar un audit de cod anonim susține că defectul descris de alții în această funcție nu există în versiunile PHP publicate. Tratați orice afirmație tehnică despre cauza problemei ca neverificată până la publicarea avizului oficial.

De ce contează

Exploatarea este incipientă și neconfirmată. Cloudflare raportează primele tentative de exploatare și a publicat reguli WAF de urgență, pe care le numește explicit o soluție temporară. O altă echipă de cercetare spune că a reprodus una dintre vulnerabilități, dar nu a raportat atacuri reale.
Nicio compromitere confirmată deocamdată. Codul proof-of-concept care circulă public nu s-a dovedit funcțional pe versiunile PHP publicate, iar niciuna dintre vulnerabilități nu figura în catalogul CISA de vulnerabilități exploatate (KEV) la data de 21 octombrie.
PHP alimentează o mare parte din web. WordPress, Laravel și nenumărate aplicații custom rulează peste un runtime PHP pe care actualizarea aplicației nu îl atinge.

Situația se poate schimba de la o oră la alta, așa că planificați pentru scenariul cel mai rău, nu pentru cel actual.

Ce trebuie făcut

Dacă puteți actualiza la 14:00 UTC

Pregătiți-vă acum: confirmați procedura de actualizare și verificările ulterioare, repetați orice modificare de configurare și asigurați oamenii și aprobările pentru o repornire de urgență.
Actualizați runtime-ul care servește traficul web (PHP-FPM, mod_php sau CGI), nu doar aplicația de deasupra.
PHP livrează remedieri doar pentru ramurile suportate, 8.2 până la 8.5.

Dacă ați dezactivat deja upload progress

Lăsați setarea dezactivată dacă nu folosiți bare de progres la upload; chiar manualul PHP recomandă acest lucru. Doar nu o considerați o protecție.
Verificați valoarea pe procesul care servește efectiv site-ul (PHP-FPM sau mod_php), nu cu php -i din linia de comandă. Fișierele .user.ini sunt citite doar de CGI/FastCGI și sunt recitite implicit la fiecare 300 de secunde; sub modulul Apache, folosiți .htaccess sau configurația serverului.

Dacă nu puteți actualiza imediat sau rulați o versiune nesuportată

Reduceți expunerea: scoateți offline aplicațiile PHP expuse la internet sau puneți-le în spatele unui VPN, al unei liste de clienți permiși sau al autentificării la margine și asigurați-vă că serverul de origine nu poate fi accesat direct, ocolind aceste controale.
Limitați impactul: reduceți datele și privilegiile de pe server, eliminați credențialele stocate (inclusiv rolurile cloud) și trimiteți logurile într-un loc pe care un atacator nu îl poate modifica.
Luați în calcul blocarea multipart/form-data la nivelul serverului web pentru toate metodele, nu doar POST, deoarece request_parse_body() din PHP 8.4 poate procesa corpuri multipart și pe alte metode. Uploadurile vor înceta să funcționeze, iar măsura vizează doar un vector suspectat.
Tratați regulile WAF ca soluție temporară: văd doar traficul care trece prin ele și pot rata vectori noi de atac.
PHP 8.1, 7.x și 5.x sunt la final de viață și nu vor primi remedieri oficiale: actualizați, izolați sau scoateți-le offline.

Dacă altcineva administrează PHP-ul vostru

Pe hosting administrat sau partajat, întrebați furnizorul când va fi disponibilă versiunea corectată. Furnizorii de hosting și distribuțiile Linux construiesc pachetele doar după lansarea oficială.
Pe Debian, Ubuntu și distribuții similare, remedierile de securitate sunt backportate, așa că un pachet corectat poate păstra un număr de versiune aparent vechi. Verificați changelog-ul pachetului sau avizul distribuției, nu șirul de versiune.

Când apare lansarea Verificați versiunea corectată pentru ramura voastră, lista oficială a versiunilor afectate, dacă PHP recomandă vreo setare ca atenuare și apoi analizați logurile pentru orice activitate dinaintea actualizării. Avizele vor fi publicate pe php.net și în GitHub security advisories ale proiectului PHP.

Cum vă poate ajuta 4Tify

Cea mai grea parte a unei astfel de urgențe este adesea să știți unde este expus PHP-ul: subdomenii uitate, servere de staging, aplicații vechi pe ramuri ieșite din suport. Serviciul nostru de Attack Surface Management cartografiază continuu activele expuse la internet și tehnologiile din spatele lor, astfel încât, la următoarea vulnerabilitate critică, aveți deja lista a ceea ce trebuie actualizat mai întâi.

Material bazat pe relatarea The Hacker News (21 octombrie 2026), rezumat independent de echipa 4Tify. Detaliile erau în evoluție la momentul redactării.