Pe scurt: Vulnerabilitatea PHP din WordPress, despre care se raportează în prezent, nu se află în WordPress, ci în PHP, pe serverul de dedesubt. O actualizare WordPress nu închide, de aceea, PHP2Shell. Decisive sunt starea patchului PHP, repornirea tuturor proceselor PHP și o verificare a ascunzătorilor tipice, precum wp-content/uploads și mu-plugins.
De ce o actualizare WordPress nu remediază PHP2Shell
WordPress este o aplicație scrisă în PHP. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 se află cu un nivel mai jos, în interpretorul PHP însuși. Potrivit echipei PHP, ele permit execuția de cod malițios la distanță, fără autentificare. La Apache cu mod_php a fost demonstrat un exploit înainte ca să ruleze vreun cod WordPress.
Un site cu nucleu actualizat, plugin-uri actualizate și parole puternice poate fi, așadar, totuși vulnerabil, dacă PHP-ul de dedesubt este vechi. Invers, un PHP cu patch aplicat nu dovedește că înainte nu s-a întâmplat nimic. Contextul îl explicăm la Ce este PHP2Shell?.
| Nivel | Cine actualizează | Închide PHP2Shell? |
|---|---|---|
| Nucleul WordPress | Dumneavoastră sau agenția dumneavoastră | Nu |
| Plugin-uri și teme | Dumneavoastră sau agenția dumneavoastră | Nu |
| PHP pe server | Furnizorul de hosting sau administratorul serverului | Da, împreună cu repornirea tuturor proceselor PHP |
Vulnerabilitatea PHP din WordPress: verificarea versiunii PHP
În panoul de administrare, la Instrumente > Starea site-ului > Informații, în secțiunea „Server”, găsiți versiunea PHP cu care rulează de fapt site-ul dumneavoastră. Aceasta este mai relevantă decât php -v în linia de comandă, deoarece linia de comandă folosește adesea o altă instalare PHP decât serverul web.
Numărul afișat nu este totuși suficient singur. Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Mulți furnizori de hosting integrează însă corecțiile ca backport; atunci rămâne afișat un număr mai vechi, deși patchul este aplicat. Cum aflați starea reală este explicat la Verificarea corectă a versiunii PHP și a stării patchului. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de WordPress verificați conform cerințelor de sistem de pe wordpress.org.
Unde se ascunde cu predilecție codul malițios în WordPress
După un atac reușit, atacatorii depun de obicei o ușă dosnică, pentru a reveni și după patch. WordPress are în acest scop locuri cunoscute:
- wp-content/uploads/: destinat imaginilor și PDF-urilor, nu fișierelor PHP.
- wp-content/mu-plugins/: plugin-urile „must-use” se încarcă automat și nu pot fi dezactivate din panoul de administrare.
- wp-config.php: conține accesul la baza de date și cheile de securitate; o linie strecurată aici se observă greu.
- .htaccess în directorul principal și în subdirectoare: redirecționări doar pentru motoarele de căutare sau execuția unor extensii de fișier neobișnuite.
- Teme, în special
functions.php, precum și plugin-uri dezactivate și uitate. - Baza de date: administratori noi în
wp_users, JavaScript străin înwp_optionssau în articole.
Primele verificări inofensive cu WP-CLI și cu mijloace de bază:
# Compararea fișierelor nucleului cu sumele de control oficiale
wp core verify-checksums
# Verificarea plugin-urilor din directorul de pe wordpress.org
wp plugin verify-checksums --all
# Listarea fișierelor PHP din directorul de upload
find wp-content/uploads -type f -name "*.php"
# Afișarea tuturor administratorilor
wp user list --role=administrator
O potrivire este un motiv pentru o analiză atentă, nu încă o dovadă. Plugin-urile comerciale nu pot fi verificate în acest fel. Detalii găsiți în ghidul Găsirea ușilor dosnice în WordPress.
Nu ștergeți în pripă fișierele suspecte. Salvați mai întâi fișierele, baza de date și jurnalele serverului începând cu 20.10.2026. Fără aceste urme nu se mai poate stabili ulterior dacă s-au scurs date.
Plugin-uri, teme și accesuri de administrator ca risc suplimentar
PHP2Shell nu are nevoie de o vulnerabilitate de plugin. În practica de zi cu zi, plugin-urile și temele rămân însă cea mai frecventă cale de intrare în site-urile WordPress. Fiecare plugin aduce cod propriu, funcții proprii de upload și cicluri proprii de actualizare. Plugin-urile nefolosite ar trebui șterse, nu doar dezactivate, deoarece fișierele dezactivate rămân pe server.
Pentru wp-login.php și wp-admin se aplică: puțini administratori, conturi personale în loc de accesuri partajate și autentificare în doi pași. Dacă nu aveți nevoie de XML-RPC, acesta poate fi blocat. După o suspiciune, toate parolele și cheile de securitate din wp-config.php ar trebui reînnoite. Tot acolo dezactivați și editorul de fișiere din panoul de administrare:
define( 'DISALLOW_FILE_EDIT', true );
Ce ar trebui să faceți acum ca operator WordPress
- Cereți furnizorului de hosting o confirmare scrisă a stării patchului PHP și a repornirii tuturor proceselor PHP.
- Cereți păstrarea jurnalelor serverului începând cu 20.10.2026.
- Efectuați verificările de mai sus sau puneți-le să fie efectuate.
- Actualizați WordPress, plugin-urile și temele. Este corect, dar nu înlocuiește pasul 1.
- În cazul unor nereguli, nu continuați pur și simplu să operați site-ul, ci puneți-l să fie curățat.
O actualizare a platformei poate închide vulnerabilități cunoscute din WordPress și din plugin-uri. Ea nu poate nici repara PHP, nici elimina fișierele strecurate care nu aparțin nucleului.
Cum ajută PHP SOS concret?
- Clarificăm cu dumneavoastră sau cu furnizorul dumneavoastră de hosting starea reală a PHP pentru site-ul dumneavoastră WordPress, inclusiv backporturile și repornirea.
- Salvăm jurnalele, fișierele și baza de date înainte de a modifica ceva.
- Verificăm nucleul, plugin-urile, uploads, mu-plugins,
.htaccessși conturile de utilizator pentru uși dosnice. - În caz de descoperiri, eliminarea malware-ului preia curățarea până când incidentul este încheiat și documentat; fără descoperiri, securizăm instalarea în cadrul ajutorului imediat PHP2Shell.
Întrebări frecvente
Trebuie să actualizez WordPress din cauza PHP2Shell?
Un WordPress actualizat este întotdeauna util, dar nu închide PHP2Shell. Vulnerabilitatea se află în interpretorul PHP al serverului. Pentru aceasta este nevoie de o actualizare PHP sau de un backport confirmat de furnizorul dumneavoastră de hosting și de repornirea tuturor proceselor PHP.
Mă protejează un plugin de securitate împotriva PHP2Shell?
Doar într-o măsură foarte limitată. Un plugin rulează el însuși ca cod PHP în interiorul WordPress. La mod_php a fost demonstrat un exploit înainte ca vreun cod al aplicației să pornească; un plugin poate să nu observe deloc un astfel de atac.
De ce afișează WordPress o versiune PHP veche, deși furnizorul de hosting a aplicat patchul?
Mulți furnizori de hosting și multe distribuții Linux integrează corecțiile ca backport în versiunea existentă. Numărul versiunii rămâne atunci același. Cereți furnizorului de hosting o confirmare scrisă a stării patchului.
Are voie să existe un fișier PHP în wp-content/uploads?
În mod normal, nu. Directorul de upload este destinat fișierelor media. Un fișier PHP acolo este un semnal de avertizare clar și ar trebui salvat și analizat de specialiști înainte de a fi șters.