PHP2Shell: două breșe critice în PHP, ce faci cu site-ul WordPress

Echipa de securitate PHP a lansat pe 21 octombrie 2026, la ora 17:00 (ora României), versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35, care repară două vulnerabilități critice din nucleul limbajului. Breșele, botezate PHP2Shell și înregistrate ca CVE-2026-109618 și CVE-2026-109619, au primit fiecare scorul 9,2 din 10 pe scala CVSS v4.0 și pot permite executarea de cod de la distanță pe server, adică preluarea controlului asupra unui site.

Problema nu ține de un plugin sau de o temă. Este în PHP, limbajul pe care rulează WordPress, Joomla, Drupal, Magento și majoritatea magazinelor online mici din România, indiferent că serverul folosește PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP sau LiteSpeed.

Ce sunt vulnerabilitățile PHP2Shell?

Pe 20 octombrie, pe Hacker News a apărut o postare care anunța două breșe de tip RCE (remote code execution) în PHP, cu dezvăluire programată pentru 22 octombrie. Firma watchTowr a confirmat că sunt reale și a reprodus una dintre ele, iar în aceeași seară echipa PHP a mutat lansarea corecturilor cu o zi mai devreme.

Avizele publicate odată cu lansarea descriu, în sfârșit, cauzele. CVE-2026-109618 apare când PHP se oprește din lipsă de memorie în timp ce datele interne ale unei cereri sunt doar parțial inițializate, iar curățarea tratează apoi date invalide ca fiind valide. CVE-2026-109619 ține de o stare internă care supraviețuiește după eliberarea memoriei și poate fi folosită de următoarea cerere procesată de același proces. Echipa PHP spune că riscul e cel mai mare pentru mod_php, unde un exploit demonstrat pornește printr-o cerere neautentificată, înainte să ruleze vreo linie din codul site-ului.

CERT-EU, echipa de răspuns la incidente a instituțiilor europene, a emis avizul 2026-018 și notează că breșele ar putea fi exploatate fără autentificare.

Sunt deja atacate site-urile?

Huntress și watchTowr spuneau la 20–21 octombrie că nu au văzut exploatare reală în mediile pe care le monitorizează. Pe de altă parte, firma Patchstack, specializată în securitatea WordPress, a raportat pe 21 octombrie dimineața mai multe incidente de exploatare activă, iar Cloudflare a vorbit despre primele atacuri.

Odată publicate corecturile, atacatorii le pot compara cu versiunea veche și pot afla exact unde e problema. Firma Sansec se așteaptă la atacuri în masă imediat după lansare, așa că fereastra în care un site neactualizat e vulnerabil se măsoară în ore.

Ce versiuni PHP primesc corectura?

Proiectul PHP repară doar ramurile încă suportate. Pentru PHP 7.4, 8.0 și 8.1, echipa de securitate a publicat doar patch-uri minimale, de aplicat manual sau prin pachetele distribuțiilor Linux, care au primit corecturile în avans.

Cifrele W3Techs din 21 octombrie arată cât de mare e problema: PHP rulează pe 69,3% dintre site-urile al căror limbaj de server e cunoscut, iar dintre acestea 27% folosesc încă PHP 7 și 7,7% PHP 5. Altfel spus, mai mult de o treime dintre site-urile PHP rulează versiuni pentru care nu există o versiune oficială reparată.

Ce trebuie să faci dacă ai un site pe WordPress?

Primul pas e să afli ce versiune de PHP folosești. În WordPress, intră în Unelte, apoi Sănătate site, fila Informații, secțiunea Server: acolo apare versiunea PHP. Pe găzduirile cu cPanel, aceeași informație apare în „Select PHP Version” sau „MultiPHP Manager”.

Dacă ești pe o găzduire partajată, actualizarea PHP o face firma de hosting, nu tu. Întreabă suportul când instalează versiunile reparate. Dacă ai un server propriu sau un VPS, aplici actualizarea din depozitele distribuției Linux sau compilezi noua versiune de pe php.net. Atenție: depozitul rpms.remirepo.net nu primește actualizarea în ziua lansării, iar echipa PHP recomandă pachetele distribuției sau compilarea din surse.

Dacă site-ul rulează pe PHP 7 sau mai vechi, mutarea pe PHP 8.2 sau mai nou nu mai poate fi amânată. Fă întâi o copie de rezervă completă, actualizează WordPress, temele și pluginurile, apoi schimbă versiunea PHP din panoul de hosting. Până atunci, echipa PHP indică măsuri temporare, precum dezactivarea opțiunii session.upload_progress.enabled direct în php.ini sau în pool-ul FPM, urmată de repornirea proceselor, plus limite mai stricte pentru dimensiunea cererilor. Cloudflare a activat și reguli de firewall pentru vectorii cunoscuți, disponibile și pe planul gratuit.

Echipa PHP subliniază că aceste setări doar reduc expunerea și nu fac instalarea sigură. Singura soluție reală rămâne versiunea reparată.

Cum îți dai seama dacă site-ul a fost deja compromis?

Huntress recomandă câteva verificări pentru cine administrează singur serverul: fișiere PHP noi în directorul site-ului, mai ales în folderul de încărcări, sarcini cron necunoscute, conturi noi de administrator și procese lansate de PHP care pornesc shell-uri sau descarcă fișiere. Dacă găsești ceva suspect, izolează serverul, păstrează jurnalele și restaurează dintr-o copie de rezervă curată.

Schimbă după aceea parolele de administrator (aceeași logică pe care o recomandăm și pentru securitatea routerului de acasă), cheile de acces FTP/SFTP și datele bazei de date.

Ce înseamnă pentru utilizatorii obișnuiți din România?

Dacă nu administrezi un site, nu ai nimic de instalat pe telefon sau pe calculator, dincolo de rutina obișnuită, cum ar fi actualizarea Windows din octombrie, care repară o breșă deja exploatată. Riscul indirect e altul: un magazin online compromis poate fi transformat în pagină de phishing. În zilele următoare, tratează cu prudență ferestrele care cer brusc date de card sau descărcarea unor „actualizări”.

Pentru firmele mici, PHP2Shell e un motiv bun să verifice contractul de mentenanță: un site făcut acum cinci ani și lăsat neatins rulează foarte probabil pe PHP 7. Iar atacul asupra Mega Image și Profi a arătat recent cât de scump iese un incident cu datele clienților.