PHP2Shell: riscuri pentru WordPress și actualizarea PHP

Un atacator trimite cereri către un site. Dacă exploatarea reușește, ajunge să execute propriul cod pe server, fără să cunoască parola de administrator. Din acel moment, poate avea acces la fișierele site-ului, la credențialele bazei de date și la informațiile pe care aplicația le poate citi.

Acesta este riscul celor două vulnerabilități PHP cunoscute sub numele PHP2Shell. Pe 21 octombrie 2026, echipa PHP a publicat actualizări pentru CVE-2026-109618 și CVE-2026-109619, ambele clasificate drept critice, cu scor CVSS v4.0 de 9,2. Remedierile sunt disponibile, iar instalările care folosesc PHP pentru cereri web trebuie verificate și actualizate. Anunțul oficial PHP

Pentru un proprietar de site WordPress, întrebarea practică este: ce ar putea face cineva după ce obține acest acces și cine trebuie să instaleze actualizarea?

Ce înseamnă executare de cod fără autentificare

PHP este motorul care execută WordPress, temele și pluginurile pe server. În mod normal, el rulează codul aplicației tale și prelucrează datele trimise de vizitatori.

O vulnerabilitate de tip remote code execution, prescurtat RCE, poate permite ca datele trimise de un atacator să ducă la executarea unui cod ales de acesta. „Fără autentificare” înseamnă că nu este necesară conectarea la un cont WordPress pentru a ajunge la calea vulnerabilă.

Reușita depinde de configurația PHP, de extensii și de comportamentul aplicației. Prezența unei versiuni afectate justifică remedierea, dar nu dovedește că site-ul a fost compromis.

Ce putea rula efectiv un atacator

Următoarele sunt consecințe posibile ale unei exploatări reușite, în funcție de permisiunile și datele accesibile procesului PHP.

Citirea fișierelor și a parolei bazei de date

WordPress trebuie să poată citi fișierul wp-config.php, care conține de regulă datele de conectare la baza de date. Un atacator care execută cod cu aceleași drepturi poate ajunge la aceste credențiale și la alte secrete accesibile aplicației.

Schimbarea parolei contului de administrator WordPress nu rezolvă singură această situație. Parola bazei de date, cheile unor servicii externe și alte credențiale expuse trebuie evaluate separat dacă există dovezi de compromitere.

Accesarea sau modificarea datelor magazinului

Cu accesul pe care aplicația îl are la baza de date, atacatorul ar putea citi ori modifica informații despre utilizatori, comenzi, adrese de livrare și conținut. Ar putea, de asemenea, să creeze un cont cu privilegii sau să schimbe setări ale magazinului.

Pentru o firmă, impactul poate însemna scurgerea datelor clienților, comenzi alterate, pierderea accesului administrativ și timp consumat pentru verificarea integrității informațiilor.

Modificarea site-ului și păstrarea accesului

Dacă procesul PHP poate scrie în directoarele site-ului, atacatorul ar putea modifica fișiere sau instala o cale de acces ascunsă, numită frecvent webshell ori backdoor. Ar putea insera pagini de phishing, redirecționări sau cod malițios în paginile vizitatorilor.

De aceea, instalarea patch-ului nu elimină automat modificările lăsate de un atac anterior. Remedierea vulnerabilității și curățarea unei compromiteri sunt operațiuni diferite.

Folosirea resurselor serverului

În limita accesului obținut, serverul ar putea fi folosit pentru trimiterea de mesaje nedorite, comunicarea cu infrastructura atacatorului sau consumarea resurselor. Efectele pot include indisponibilitate, încărcare neobișnuită și afectarea reputației domeniului sau a adresei IP.

Codul rulează inițial cu drepturile procesului web. Accesul la alte site-uri, backupuri sau servicii depinde de izolarea dintre ele, de permisiuni și de eventuale alte probleme. Un cont separat pentru fiecare site și credențiale distincte limitează ce poate fi atins după o compromitere.

Ce era greșit în PHP

Cele două probleme privesc gestionarea memoriei și a stării interne a cererilor.

CVE-2026-109618: când PHP rămânea fără memorie, putea întrerupe o operațiune înainte ca datele interne să fie complet inițializate. La închiderea cererii, putea folosi acele date invalide. În condiții potrivite, acest comportament permite executarea de cod. Explicația tehnică a echipei PHP

CVE-2026-109619: un proces PHP putea păstra, între două cereri, referințe către memorie deja eliberată. O cerere ulterioară, prelucrată de același proces, putea folosi acele referințe înainte ca starea internă să fie resetată. Detaliile celei de-a doua vulnerabilități

Echipa PHP a demonstrat exploatarea pe Apache cu mod_php, inclusiv înainte de rularea codului aplicației. Pentru PHP-FPM, condițiile diferă: documentația descrie și o cale validată pentru a doua problemă, dependentă de o operațiune potrivită din aplicație. Folosirea Nginx cu PHP-FPM nu justifică omiterea actualizării.

De ce actualizarea WordPress nu este suficientă

PHP are propriul ciclu de actualizare, separat de WordPress, teme și pluginuri. Poți avea toate componentele din administrarea WordPress la zi și totuși să folosești un pachet PHP vulnerabil.

Pe găzduire administrată, actualizarea PHP revine în mod obișnuit furnizorului. Pe un VPS administrat de tine sau de colaboratorul tău tehnic, responsabilitatea trebuie stabilită explicit.

Un plugin de securitate poate adăuga protecții, dar nu înlocuiește remedierea motorului PHP. Echipa PHP precizează că actualizarea este singura soluție completă; măsurile temporare de configurare reduc doar anumite căi de atac.

Ce versiuni conțin remedierile

La data publicării, versiunile oficiale remediate din ramurile susținute sunt:

PHP 8.2: 8.2.35;
PHP 8.3: 8.3.36;
PHP 8.4: 8.4.27;
PHP 8.5: 8.5.12.

Folosește aceste versiuni sau versiuni ulterioare care includ remedierile. Pentru ramurile mai vechi, verifică suportul furnizorului și existența unui patch confirmat; simpla selectare a unei versiuni vechi în panoul de hosting nu oferă această garanție. Versiunile și recomandările oficiale

De ce Ubuntu poate afișa în continuare PHP 8.3.6

Distribuțiile Linux pot aplica remedierea peste versiunea pe care o întrețin, fără să schimbe numărul principal afișat de PHP. Acest lucru se numește backport.

Pentru Ubuntu 24.04 LTS, pachetul `8.3.6-0ubuntu0.24.04.13` remediază ambele CVE-uri. Așadar, două servere care afișează „PHP 8.3.6” pot avea stări de securitate diferite. Trebuie verificată versiunea completă a pachetului și confirmarea distribuitorului. Buletinul Ubuntu USN-8948-1

Ce să ceri firmei de hosting

Poți trimite o solicitare concretă: „Vă rog să confirmați că instanța PHP care deservește site-ul meu conține remedierile pentru CVE-2026-109618 și CVE-2026-109619 și că procesele PHP au fost repornite după actualizare.”

Cere confirmarea versiunii complete a pachetului și verificarea tuturor instalărilor: site principal, subdomenii, staging și demo-uri. O versiune verificată în terminal poate aparține altui executabil decât cel care servește efectiv site-ul.

După instalare, verifică paginile dinamice, autentificarea, formularele și, pentru WooCommerce, coșul și finalizarea comenzii. Verificarea trebuie făcută și fără cache, pentru a confirma că noul PHP execută aplicația.

Cum verifici dacă site-ul a fost atacat

Analiza începe cu logurile serverului web și PHP, apoi continuă cu fișierele, conturile și datele aplicației. Caută cereri neobișnuite corelate cu erori, fișiere executabile apărute în directoarele de upload, modificări neexplicate, conturi noi și conexiuni sau procese suspecte.

Un răspuns HTTP 200 nu demonstrează că atacatorul a executat cod. Un răspuns 404 nu descrie singur întregul context al unei cereri. Nici lipsa erorilor nu certifică absența unui atac: logurile obișnuite nu păstrează corpul cererilor POST și pot să nu surprindă toate operațiunile relevante.

Dacă apar indicii de compromitere, păstrează logurile și o copie a fișierelor pentru investigație, limitează accesul la instanța afectată și implică administratorul serverului. Rotirea credențialelor trebuie coordonată cu eliminarea accesului atacatorului, ca noile parole să nu fie expuse din nou.

O scanare externă WordPress ajută la inventarierea componentelor vizibile public. Confirmarea patch-ului PHP și investigarea unei compromiteri necesită acces autorizat la hosting sau server.

Ce am făcut pe infrastructura noastră

Am inventariat instanțele PHP, am verificat logurile disponibile și am căutat modificări recente în fișiere. În verificările efectuate nu am identificat dovezi de exploatare PHP2Shell. Am păstrat însă limita acestei concluzii: lipsa urmelor în logurile disponibile nu exclude absolut o compromitere.

După apariția pachetului oficial Ubuntu, am salvat configurația, am actualizat PHP și extensiile instalate și am repornit PHP-FPM. Am verificat apoi randarea ambelor instalări demonstrative prin PHP, inclusiv cea protejată prin parolă. Paginile au fost generate fără erori PHP, iar configurația existentă a fost păstrată.

Acesta este un exemplu de intervenție care trebuie inclusă în mentenanța WordPress: cineva urmărește alertele, verifică infrastructura și confirmă că remedierea chiar a fost aplicată.

Surse

Informații verificate la 21 octombrie 2026, după publicarea remedierilor. Condițiile tehnice și versiunile sunt cele descrise în documentația disponibilă la această dată.

Vrei să verifici dacă site-ul tău este expus?

Rulează gratuit scanarea de securitate. Dacă apar riscuri sau versiuni ascunse, continuăm cu un audit tehnic.

Scanează securitatea gratuit Vezi serviciul de securitate WordPress