PHP2Shell: vulnerabilitățile critice din PHP explicate

Două vulnerabilități critice din interpretorul PHP, cunoscute sub numele PHP2Shell (CVE-2026-109618 și CVE-2026-109619), permit executarea de cod pe server fără autentificare. Echipa PHP le-a evaluat cu scorul CVSS v4.0 9.2 din 10 și lansează corecțiile pe 21 octombrie 2026, la ora 17:00 (ora României).

Problema nu ține de WordPress, Magento sau de o altă aplicație anume, ci de PHP însuși. Prin urmare, orice site care rulează PHP este potențial expus, indiferent de platforma folosită. Detaliile au ajuns publice înainte ca patch-ul să fie disponibil iar tentativele de exploatare au început deja.

Ce trebuie făcut: actualizați PHP la o versiune corectată imediat ce aceasta este disponibilă. Măsurile temporare descrise mai jos reduc riscul până atunci, dar nu îl elimină.

Articolul reflectă informațiile disponibile la data publicării. Îl vom actualiza după lansarea oficială a corecțiilor.

Ce știm până acum

Sunt confirmate două vulnerabilități critice de tip execuție de cod de la distanță (RCE), fiecare cu scorul CVSS v4.0 9.2. Echipa de securitate PHP a publicat pe 20 octombrie un anunț prealabil despre lansarea de urgență, fără detalii tehnice. Firma de securitate watchTowr a confirmat ulterior că vulnerabilitățile sunt reale și că a reprodus una dintre ele.

Componenta afectată nu a fost confirmată oficial de echipa PHP. Analizele independente și codul demonstrativ apărut public indică mecanismul session.upload_progress, funcția care urmărește progresul încărcării fișierelor și care este activă implicit în PHP.

Versiunile corectate au fost anunțate înainte de lansare și trebuie verificate în anunțul oficial de pe php.net. Conform rapoartelor, sunt afectate toate versiunile începând cu PHP 5.4, adică practic tot ce rulează astăzi în producție.

Cronologie

În mai puțin de 24 de ore, vulnerabilitățile au trecut de la secret de embargo la exploatare activă. Orele sunt în ora României (EEST).

Scurgerea a scurtat perioada în care administratorii se puteau pregăti. De aceea, regulile WAF și setările temporare au devenit importante în orele dinaintea patch-ului.

Cum funcționează atacul

Atacul se produce în PHP înainte ca aplicația să ruleze, așa că protecțiile din aplicație nu îl pot opri. Descrierea de mai jos se bazează pe analize independente; detaliile oficiale vor fi publicate odată cu patch-ul.

1. Atacatorul trimite o cerere de tip multipart/form-data, formatul folosit de browsere pentru formulare și încărcări de fișiere, către orice fișier PHP de pe site.
2. Cererea conține un câmp special care activează mecanismul de urmărire a progresului încărcării (session.upload_progress), activ implicit.
3. PHP prelucrează acest câmp și scrie date în sesiune înainte de a executa scriptul aplicației.
4. O eroare de gestionare a memoriei (de tip use-after-free) în acest cod poate fi exploatată pentru a executa comenzi pe server.

De aici rezultă trei consecințe practice:

• Orice fișier PHP este o țintă, chiar dacă site-ul nu folosește sesiuni sau formulare de încărcare.
• Autentificarea nu contează, pentru că atacul are loc înainte de logarea în aplicație.
• Actualizările aplicației nu ajută. Un WordPress sau un modul la zi rămâne vulnerabil dacă PHP-ul de dedesubt nu este actualizat.

Riscuri și impact

Atacatorul obține controlul cu drepturile utilizatorului sub care rulează PHP. Cât de grav este depinde de modul în care este configurat serverul.

Consecințele tipice ale unei compromiteri:

• Fișiere modificate sau șterse: defacement, redirecționări, conținut spam pentru SEO.
• Programe malițioase instalate: webshell-uri, scripturi de phishing, trimitere de spam, mineri de criptomonede.
• Date furate: fișierele de configurare conțin parolele bazei de date, deci datele clienților, comenzile și conturile pot fi extrase.
• Magazine online: injectarea de cod care fură datele cardurilor la plată (atacuri de tip Magecart).
• Obligații legale: o breșă care implică date personale poate impune notificarea autorității (ANSPDCP în România, CNIL în Franța) în 72 de ore, conform GDPR.

Soluția: actualizarea PHP

Singura protecție completă este rularea unei versiuni PHP corectate; echipa PHP a declarat explicit că setările de configurare nu sunt suficiente. Actualizarea se face pe server, nu în aplicație.

Pe găzduire partajată nu aveți nimic de instalat: furnizorul de găzduire actualizează PHP. Puteți, în schimb, să alegeți din panoul de control o versiune suportată (8.3 sau 8.4), dacă folosiți una mai veche.

Pe VPS sau server dedicat actualizați pachetele PHP din sursa pe care o folosiți:

Depozitul Remi, folosit des pe serverele RHEL, nu publică actualizări în ziua lansării, conform Fundației PHP. Dacă îl folosiți, urmăriți anunțurile sale sau treceți temporar la altă sursă.

Cum verificați că actualizarea conține corecția. Numărul versiunii nu este suficient, pentru că distribuțiile pot aplica corecția pe o versiune mai veche. Căutați codul CVE în istoricul pachetului:

rpm -q --changelog php | grep -i 109618
apt changelog php8.3-cli | grep -i 109618

După actualizare, reporniți serviciile PHP-FPM, LSAPI sau Apache, astfel încât procesele să ruleze noua versiune.

Măsuri temporare până la actualizare

Măsurile de mai jos reduc riscul în orele sau zilele până la actualizare, dar niciuna nu oferă protecție completă. Folosiți-le împreună, nu în locul patch-ului.

1. Dezactivarea upload progress în PHP

Setarea închide calea de atac descrisă public, dar dezvoltatorii PHP avertizează că nu acoperă toate variantele. În php.ini:

session.upload_progress.enabled = 0
session.use_strict_mode = 1
session.use_only_cookies = 1

Pentru PHP-FPM, adăugați în fiecare pool (de exemplu /etc/php/8.3/fpm/pool.d/www.conf):

php_admin_flag[session.upload_progress.enabled] = off

Pe serverele cu mai mulți utilizatori, folosiți php_admin_flag, nu php_flag. Varianta „admin” nu poate fi suprascrisă de un fișier .user.ini sau .htaccess din contul unui client. Funcția dezactivată afișează doar bare de progres native PHP, pe care platformele populare nu le folosesc.

Ce nu ajută: file_uploads = Off, pentru că PHP prelucrează oricum corpul cererii multipart.

2. Reguli WAF pe server

• Imunify360: setul de reguli ModSecurity 8.83 blochează forma publică a exploit-ului și se instalează automat pe serverele cu WAF activ. Verificați versiunea în fișierul VERSION al setului de reguli.
• ModSecurity fără Imunify360: o regulă care blochează cererile ce conțin câmpul PHP_SESSION_UPLOAD_PROGRESS:

SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" "id:1009618,phase:2,deny,status:403,log,msg:'php2shell'"

Regula funcționează doar cu SecRequestBodyAccess On și oprește doar variantele cunoscute ale atacului.

3. Cloudflare

Cloudflare a activat reguli pentru acest atac pentru toți clienții, inclusiv pe planul gratuit; verificați că regulile gestionate (Managed Rules) sunt active. Pentru protecție suplimentară, puteți bloca cererile multipart pe site-urile care nu au nevoie de încărcări. Atenție: multe formulare, de exemplu tichetele de suport, trimit multipart chiar fără fișier atașat.

4. Blocarea accesului direct la server

Un WAF din cloud protejează doar traficul care trece prin el. Dacă atacatorul află adresa IP reală a serverului, ocolește filtrarea. Restricționați porturile 80 și 443 la intervalele IP Cloudflare, din firewall (CSF, iptables, Windows Firewall) sau din configurația serverului web. Verificați apoi certificatele Let’s Encrypt cu validare HTTP, care pot eșua după restricționare.

5. Oprirea temporară

Pentru site-urile neesențiale, oprirea până la actualizare este cea mai sigură variantă. Un dezvoltator PHP a recomandat-o explicit pentru serverele care își permit o zi de nefuncționare.

Versiuni PHP vechi și servere Windows

PHP 8.1 și versiunile mai vechi

Echipa PHP corectează doar ramurile 8.2–8.5, deci PHP 5.4–8.1 nu primește patch oficial. Unele surse adaptează corecția și pentru versiunile vechi:

• CloudLinux (alt-php, ea-php) urmează să publice pachete actualizate și le anunță pe pagina de status.
• Distribuțiile Linux cu suport extins pot aplica corecția pe propriile pachete; verificați anunțurile de securitate ale distribuției.

Chiar și cu o corecție adaptată, recomandarea rămâne trecerea la PHP 8.3 sau 8.4. Versiunile vechi depind de corecții neoficiale, care pot apărea mai târziu sau deloc pentru vulnerabilitățile viitoare. PHP 8.2 primește această corecție, dar suportul său de securitate se încheie pe 31 decembrie 2026.

Windows (IIS, Plesk pentru Windows)

Vulnerabilitatea este în PHP, nu în sistemul de operare, deci site-urile PHP de pe servere Windows sunt la fel de expuse. Site-urile care folosesc exclusiv ASP.NET nu sunt afectate.

• Imunify360 nu este disponibil pe Windows, deci nu există strat WAF pe server; protecția vine din actualizare și din Cloudflare.
• Actualizați PHP prin Plesk (Tools & Settings → Updates) sau cu versiunile oficiale de pe windows.php.net.
• Setarea session.upload_progress.enabled = 0 se aplică în php.ini la fel ca pe Linux.
• Restricționarea porturilor 80/443 la IP-urile Cloudflare se face din Windows Firewall.
• Versiunile vechi de PHP pe Windows nu primesc corecții adaptate; singura soluție este o versiune suportată.

Cum verificați dacă ați fost compromis

Actualizarea oprește atacurile noi, dar nu elimină un acces deja obținut. Verificați perioada de la 20 octombrie până la momentul actualizării.

Semne de avertizare:

• fișiere PHP noi sau modificate pe care nu le recunoașteți, mai ales în directoare de încărcări, cache sau teme;
• fișiere de sesiune (sess_*) neobișnuite în directorul de sesiuni, cu conținut legat de upload progress;
• cereri POST multipart către fișiere PHP care în mod normal nu primesc formulare, în jurnalele serverului web;
• redirecționări neașteptate, spam trimis din cont, conturi de administrator noi în aplicație;
• alerte Imunify360, ImunifyAV sau ale altui antivirus de server.

Verificări rapide pe server:

# fișiere PHP modificate după 20 octombrie
find /home/*/public_html -name '*.php' -newermt '2026-10-20' -type f

# cereri multipart în jurnalele Apache/LiteSpeed (formatul diferă de la server la server)
grep -i 'multipart' /var/log/apache2/access.log

Dacă găsiți semne de compromitere:

1. Izolați site-ul sau serverul afectat.
2. Restaurați dintr-o copie de siguranță anterioară datei de 20 octombrie.
3. Schimbați toate parolele și cheile: panou de control, FTP/SFTP, baza de date, administrarea aplicației, chei API.
4. Actualizați PHP înainte de a repune site-ul online.
5. Evaluați dacă au fost expuse date personale și dacă este necesară notificarea conform GDPR.

Ce face HostX

Serverele de găzduire partajată HostX sunt protejate de regulile WAF Imunify360, iar PHP va fi actualizat imediat ce pachetele corectate sunt disponibile.

• Găzduire partajată Linux: regulile Imunify360 care blochează exploit-ul public sunt active. Conturile sunt izolate prin CloudLinux CageFS. Actualizăm PHP pe toate serverele imediat după publicarea pachetelor de către furnizori (CloudLinux, cPanel, DirectAdmin, Plesk).
• Găzduire Windows: actualizăm versiunile PHP din Plesk imediat ce sunt disponibile.
• VPS și servere dedicate: [pentru serverele administrate de HostX, aplicăm noi actualizarea; pentru cele administrate de client, recomandăm pașii din acest articol].
• Asistență: dacă aveți nevoie de ajutor pentru actualizare, configurarea Cloudflare, licență Imunify360 sau verificarea unui site, deschideți un tichet.

[Actualizare: data și ora finalizării actualizărilor pe infrastructura HostX.]

Concluzie

PHP2Shell este una dintre cele mai serioase vulnerabilități PHP din ultimii ani: afectează practic toate versiunile, nu necesită autentificare și a devenit publică înainte de patch. Actualizarea PHP este obligatorie; regulile WAF, Cloudflare și setările temporare doar câștigă timp. Dacă folosiți încă PHP 8.1 sau o versiune mai veche, acesta este momentul să treceți la 8.3 sau 8.4.

Surse

• Sansec – Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• Tenable – php2shell FAQ
• SecurityWeek – PHP2Shell: Mass Exploitation Looms
• Aikido – Critical vulnerabilities in PHP
• ma.ttias.be – Early mitigation steps
• Vincent Schmalbach – What you should do now
• PatchMon – Patching across your fleet
• CloudLinux – Disponibilitatea pachetelor actualizate
• Anunțul PHP din 20 octombrie 2026
• Cloudflare – Intervale IP