wp2shell: vulnerabilitatea din WordPress Core și ce trebuie să verifici acum pe site-ul firmei

Pe 17 iulie 2026, site-ul tău WordPress s-a actualizat singur. Probabil nici nu ai observat — un email automat de la WordPress, poate nici măcar atât. Update-ul acela nu era unul de rutină: WordPress a împins forțat versiunile 6.9.5 și 7.0.2 prin sistemul de auto-update, ceea ce nu se întâmplă des.

Motivul: un lanț de două vulnerabilități din WordPress Core — nu dintr-un plugin, nu dintr-o temă — care, combinate, permiteau unui atacator neautentificat să execute cod pe o instalare standard. Cercetătorii de la Searchlight Cyber, care l-au descoperit, i-au spus wp2shell.

A trecut aproape o lună. Valul inițial de exploatare a trecut. Patch-ul e aplicat pe majoritatea site-urilor. Și totuși articolul ăsta are rost, dintr-un motiv foarte concret: update-ul te protejează de atacuri noi, dar nu șterge un backdoor instalat înainte de update. Dacă site-ul tău a fost prins în fereastra dintre exploit-ul public și momentul actualizării, contul de admin al atacatorului e încă acolo. Și încă funcționează.

Răspuns scurt

Trei pași, în ordinea asta:

1. Verifică ce versiune de WordPress rulezi. Panou admin → Tablou de bord → Actualizări. Dacă ești pe 6.9.5, 7.0.2 sau mai nou, ești patchuit. Dacă ești pe 6.9.0–6.9.4 sau 7.0.0–7.0.1, ești vulnerabil chiar acum și trebuie să actualizezi în următoarele minute.
2. Actualizează, dacă nu ești deja actualizat. Nu e o discuție, nu e o planificare pentru săptămâna viitoare.
3. Verifică dacă ai fost compromis — conturi de admin necunoscute, plugin-uri pe care nu le-ai instalat, fișiere PHP străine în wp-content. Detaliile sunt mai jos. Acest pas e cel pe care aproape toată lumea îl sare.

Dacă ai fost pe o versiune anterioară lui 6.9, poți opri lectura aici cu conștiința curată: nu ești afectat de asta.

Ce este, de fapt, wp2shell

Sunt două probleme separate, care singure ar fi fost neplăcute, dar împreună au fost grave.

CVE-2026-63030 este o eroare de logică în procesorul de cereri batch din REST API-ul WordPress, endpoint-ul /wp-json/batch/v1. Pe scurt: validarea sub-cererilor și execuția lor se fac în două bucle diferite. Când wp_parse_url() eșuează pe calea unei sub-cereri, eroarea e înregistrată într-o structură, dar nu și în cea folosită la execuție. Rezultatul e o cerere care „trece” pe lângă validare. Problema a apărut pe ramura 6.9.

CVE-2026-60137 este o injecție SQL în parametrul author__not_in din WP_Query. Când parametrul e trimis ca șir simplu în loc de listă, ajunge direct în interogarea SQL brută, neescapat.

Legate una de alta, cele două dau execuție de cod la distanță, fără autentificare, pe o instalare WordPress implicită. De aceea reacția a fost atât de dură: nu e nevoie de un plugin obscur instalat, nu e nevoie de o parolă slabă, nu e nevoie ca atacatorul să fie logat.

Nu voi intra în detalii de exploatare și nu găsești aici cod. Articolul ăsta e defensiv: cum verifici, cum repari, cum îți recuperezi site-ul.

Ce versiuni sunt afectate

Asta e partea cea mai importantă din tot articolul, așa că o pun separat:

Versiune WordPress	Situație
Mai vechi de 6.9	Nu este afectat
6.9.0 – 6.9.4	Vulnerabil
6.9.5	Patchuit (17 iulie 2026)
7.0.0 – 7.0.1	Vulnerabil
7.0.2	Patchuit (17 iulie 2026)
7.1 Beta 2	Patchuit

WordPress a lansat 6.9.5, 7.0.2 și 7.1 Beta 2 pe 17 iulie 2026 și le-a împins forțat prin sistemul de actualizări automate — un pas neobișnuit, rezervat situațiilor în care riscul e considerat prea mare pentru ritmul normal de update.

Cum verifici versiunea în 10 secunde: intri în admin, Tablou de bord → Actualizări. Scrie acolo, în clar, „Rulezi versiunea X.Y.Z”. Alternativ, în Instrumente → Sănătatea site-ului → Informații → WordPress.

Cine NU este afectat

Merită spus limpede, pentru că panica generalizată nu ajută pe nimeni:

• Site-urile pe WordPress mai vechi de 6.9 nu sunt afectate de acest lanț. Vulnerabilitatea a fost introdusă pe ramura 6.9. Dacă rulezi 6.7 sau 6.8, wp2shell nu te privește. (Asta nu înseamnă că a rula o versiune veche e o idee bună — ai alte probleme, doar nu asta.)
• Site-urile cu actualizări automate active, care s-au actualizat normal pe 17 iulie, au primit patch-ul înainte ca majoritatea încercărilor de exploatare să înceapă. Fereastra lor de expunere a fost foarte scurtă sau inexistentă.
• Site-urile care nu rulează WordPress — Next.js, Astro, Laravel, orice altceva — evident, nu au acest endpoint.

Dacă ești în una dintre categoriile de mai sus și panoul de admin arată curat, probabil chiar ești în regulă. Nu ai nevoie de noi pentru asta.

De ce nu s-a terminat cu patch-ul

Aici e nuanța pe care o ratează aproape toată lumea, inclusiv oameni tehnici.

Un exploit public a apărut pe GitHub la câteva ore după publicarea patch-ului. Searchlight Cyber (echipa Assetnote, cercetătorul Adam Kues) publicase advisory-ul pe 17 iulie, iar analiza tehnică completă pe 22 iulie. Honeypot-urile au înregistrat, după apariția exploit-ului public, zeci de mii de încercări de exploatare.

Tiparul post-exploatare raportat e consistent: atacatorul își creează un cont de administrator, se loghează normal prin wp-login.php ca orice utilizator, apoi încarcă un plugin malițios ca să obțină execuție de cod stabilă. Din activitatea raportată public fac parte webshell-uri PHP scrise în căi randomizate în interiorul wp-content, protejate cu token de autentificare generat per rulare; peste 100 de conturi de administrator backdoor create; și un webshell de circa 150 KB deghizat într-un plugin de securitate cu nume credibil, „CMSmap”, cu manager de fișiere, acces la baza de date, scanare de porturi și escaladare de privilegii.

Acum urmărește logica: dacă atacatorul a intrat pe 18 iulie și și-a creat un cont de admin, iar site-ul tău s-a actualizat pe 20 iulie — patch-ul închide ușa prin care a intrat, dar contul lui de admin rămâne. Pluginul rămâne. Webshell-ul din wp-content rămâne. Toate funcționează în continuare, pe un WordPress perfect actualizat.

Asta e diferența dintre „patchuit” și „curat”. Sunt două lucruri diferite, iar prima nu o implică pe a doua.

Cum verifici concret dacă ai fost afectat

Ordinea contează. Fă-le pe rând, nu sări peste.

1. Verifică versiunea și data ultimei actualizări. Dacă WordPress s-a actualizat automat pe 17 sau 18 iulie, fereastra ta de expunere a fost mică. Dacă s-a actualizat abia în august, sau dacă nu s-a actualizat deloc până acum, tratează site-ul ca potențial compromis până demonstrezi contrariul.

2. Verifică lista de utilizatori. Panou admin → Utilizatori → Toți utilizatorii, filtrează după rolul Administrator. Trebuie să recunoști fiecare cont din listă: numele, adresa de email, data înregistrării. Un cont de admin pe care nu îl recunoști este, până la proba contrarie, un cont al atacatorului. Sortează după data înregistrării — conturile create în a doua jumătate a lunii iulie merită atenție specială.

3. Verifică lista de plugin-uri. Panou admin → Plugin-uri → Plugin-uri instalate. Uită-te la tot, inclusiv la cele inactive. Orice plugin pe care nu l-ai instalat tu sau dezvoltatorul tău e suspect, indiferent cât de legitim sună numele. Un plugin de „securitate” pe care nu-ți amintești să-l fi instalat e exact tiparul raportat.

4. Verifică fișierele PHP din wp-content. Prin File Manager-ul din cPanel sau prin FTP, uită-te după fișiere .php în locuri unde n-ar trebui să existe — mai ales în wp-content/uploads/, care ar trebui să conțină doar imagini și documente. Sortează directoarele după data modificării: fișiere modificate sau create în iulie, pe care nu le poți explica printr-o acțiune de-a ta, sunt semnalul principal. Numele lor sunt de obicei aleatorii, nu evidente.

5. Verifică logurile de acces HTTP. În cPanel, la Metrics → Raw Access sau Logs, caută cereri către /wp-json/batch/v1. Un site normal de firmă nu primește trafic pe acest endpoint. Un volum de cereri acolo, în a doua jumătate a lui iulie, înseamnă că cineva a încercat. Nu înseamnă automat că a reușit — dar înseamnă că pașii 2, 3 și 4 devin obligatorii, nu opționali.

6. Verifică Google Search Console și Safe Browsing. Pagini pe care nu le-ai creat, avertizări de securitate, creșteri bruște de URL-uri indexate. Nu toate compromiterile ajung aici, dar când ajung, e clar.

Regula de bază pe tot parcursul: nu șterge nimic în graba primului minut. Fă întâi o copie completă a fișierelor și a bazei de date, chiar infectate. Dacă ștergi de la început, pierzi dovezile care îți spun pe unde a intrat și dacă a mai lăsat ceva.

Dacă găsești ceva

Un cont de admin necunoscut sau un fișier PHP suspect în uploads nu se rezolvă ștergându-l pe acela. Tiparul e clar din raportările publice: atacatorii lasă mai multe puncte de revenire. Ștergi webshell-ul, ei revin prin contul de admin. Ștergi contul, revin prin plugin. Ștergi pluginul, revin printr-un al doilea fișier pe care nu l-ai găsit.

Curățarea corectă înseamnă: backup forensic, înlocuirea WordPress Core cu sursă curată, audit complet de utilizatori, verificarea tuturor plugin-urilor și temelor, scanarea bazei de date, resetarea parolelor, a cheilor de securitate (salts) și a token-urilor, verificarea .htaccess, a cron-urilor și a permisiunilor. Am detaliat pașii, cu ce nu trebuie șters și de ce, în ghidul nostru despre ce faci când site-ul WordPress e hackuit.

Dacă preferi să nu faci asta singur, exact aici intervenim: curățare malware WordPress cu scanare de fișiere, bază de date, utilizatori, plugin-uri și accesuri. Pentru urgențe există pagina dedicată pentru site WordPress hackuit, iar dacă infecția e vizibilă pentru vizitatori sau în Google, devirusare site WordPress. Scrie-ne cu versiunea de WordPress, data ultimei actualizări și ce ai găsit la pașii 2–5 de mai sus — cu informațiile astea îți putem spune destul de repede cât de serioasă e situația.

Nu îți promitem că orice site compromis se recuperează perfect. Depinde de cât timp a stat atacatorul înăuntru și de ce a apucat să atingă. Îți promitem că nu ștergem un fișier și declarăm victorie.

Dacă e curat

Foarte probabil ești în acest caz, mai ales dacă auto-update-urile au funcționat. Atunci mai ai de făcut un singur lucru: să te asiguri că data viitoare update-ul critic ajunge la fel de repede.

Concret, asta înseamnă actualizări automate active pentru core, backup-uri care se testează (nu doar se fac), un număr mic de plugin-uri, toate întreținute, 2FA pe conturile de admin și cineva care se uită lunar la site, nu doar când se strică. Am scris separat ce înseamnă concret mentenanța WordPress, pe cadență, inclusiv ce poți face singur. Dacă nu ai pe cineva care face asta, e exact conținutul unui abonament de mentenanță website firmă.

Iar dacă site-ul tău e o prezentare de firmă — pagini de servicii, formular de contact, blog rar actualizat — merită întrebarea onestă dacă mai are nevoie de WordPress. Un site static, fără PHP care rulează la fiecare vizită și fără panou de admin public, nu are cum să fie afectat de o vulnerabilitate în REST API-ul WordPress. Nu e răspunsul potrivit pentru toată lumea, dar pentru multe site-uri de firmă este — discuția completă, cu costuri și un decision tree, e în WordPress vs Next.js pentru firma ta.

Concluzie

wp2shell a fost o problemă reală în WordPress Core, patchuită rapid și distribuită forțat pe 17 iulie 2026. Dacă rulezi 6.9.5, 7.0.2 sau mai nou, ușa e închisă. Dacă rulezi ceva mai vechi de 6.9, nu a fost niciodată deschisă pentru tine.

Întrebarea care rămâne, la o lună distanță, nu mai e „sunt vulnerabil?”, ci „am fost prins în fereastra de expunere?”. Se răspunde în cincisprezece minute, uitându-te la lista de utilizatori, la lista de plugin-uri și la fișierele din wp-content.

Fă verificarea. În cel mai probabil caz, vei descoperi că totul e în regulă și îți vei fi cheltuit un sfert de oră degeaba — cea mai bună variantă posibilă.