Două vulnerabilități critice din WordPress Core permit preluarea completă a site-urilor, fără autentificare

O nouă vulnerabilitate din nucleul WordPress zguduie ecosistemul care alimentează peste 40% din web-ul mondial. Denumită wp2shell, este de fapt un lanț format din două vulnerabilitati separate: CVE-2026-63030 și CVE-2026-60137 care, combinate, permit unui atacator neautentificat să execute cod la distanță (RCE) pe o instanta WordPress standard.

Partea cu adevărat periculoasă: atacul nu are nevoie de niciun cont, de niciun plugin vulnerabil și de nicio configurație specială. Vulnerabilitatea trăiește în însuși codul WordPress Core, nu în teme sau plugin-uri terțe. Cu alte cuvinte, orice site pe o versiune afectată, chiar «curat», proaspăt instalat, este expus. Există deja exploit-uri publice, iar exploatarea a fost confirmată la câteva zile de la dezvăluire.

Cele două vulnerabilități pe scurt

Scorurile CVSS diferă în funcție de sursă. Pentru CVE-2026-63030, autoritatea WPScan a alocat 9.8 (Critic), în timp ce evaluarea CISA-ADP / NVD indică 7.5 (Ridicat). Indiferent de cifră, ceea ce contează este rezultatul final al lanțului: preluarea completă a site-ului de către un atacator care nu are niciun fel de acces prealabil.

Cum funcționează lanțul de atac

Fascinația cercetătorilor față de wp2shell vine din eleganța înlănțuirii: patru pași mici, fiecare aparent inofensiv, care împreună duc la compromitere totală.

1. Confuzia de rute (CVE-2026-63030)

Endpoint-ul batch din REST API procesează mai multe cereri deodată, ținând în paralel trei liste: cererile, potrivirile de rută și rezultatele validării. Când o cerere nu poate fi parsată corect, WordPress nu adaugă un loc rezervat în lista de potriviri — indicii se desincronizează. Rezultatul: cereri nevalidate ajung la handler-e pentru care nu au fost niciodată verificate.

2. SQL Injection prin WP_Query (CVE-2026-60137)

Odată ce o cerere nevalidată ajunge la handler-ul de postări, parametrul author__not_in ocolește sanitizarea. Codul curăță valoarea doar dacă este deja un array; un string scalar brut trece direct în interogarea SQL. Astfel apare injecția, care îi dă atacatorului control asupra a ceea ce returnează interogarea.

3. Otrăvirea obiectelor din cache

Controlând rezultatul interogării, atacatorul poate «fabrica» obiecte WP_Post false, stocate în memorie, cu valori alese de el pentru câmpuri precum status, tip și părinte. Practic, WordPress crede că lucrează cu postări legitime.

4. Salvări imbricate și cont de administrator

Ultimul pas exploatează calea de scriere oEmbed împreună cu sistemul de changeset-uri Customizer și hook-urile din loader-ul REST. Prin salvări imbricate de postări, WordPress ajunge să ruleze temporar cu drepturi de administrator. În acest moment, cererea inițială respinsă de creare de utilizator trece cu succes: se creează un cont de admin, care apoi permite instalarea unui plugin — și, de acolo, execuția de cod arbitrar pe server.

Ce versiuni sunt afectate și unde e patch-ul

Lanțul complet de RCE necesită ambele defecte, deci vizează ramurile care conțin endpoint-ul batch (6.9 și 7.0). Componenta de SQL injection există însă din 6.8, motiv pentru care și acea ramură a primit patch.

Patch-urile au fost publicate pe 17 iulie 2026 (versiunile 6.8.6, 6.9.5, 7.0.2, plus 7.1 Beta 2). Din cauza gravității, echipa WordPress a făcut un pas neobișnuit: a forțat actualizarea automată de securitate către toate instalările suportate. Chiar și așa, administratorii trebuie să confirme că patch-ul chiar s-a aplicat — auto-update-ul poate eșua din diverse motive (permisiuni, dezactivări manuale, hosting restrictiv).

Exploatare activă și cronologie

Confuzia de rute a fost descoperită de Adam Kues (Searchlight Cyber), iar componenta de SQL injection este creditată cercetătorilor TF1T, dtro și haongo. La câteva ore după dezvăluirea din 17 iulie, pe GitHub au apărut mai multe exploit-uri publice (unele generate cu ajutorul instrumentelor AI) — de la scripturi care extrag hash-urile parolelor de admin prin SQL injection, până la lanțuri complete de RCE preautentificat.

În weekendul de 20 iulie 2026, firme de securitate precum watchTowr, Patchstack și Hexastrike au raportat primele semne de exploatare în sălbăticie. Pe 21 iulie, vulnerabilitatea a fost adăugată în catalogul CISA KEV (Known Exploited Vulnerabilities). Cloudflare a implementat între timp reguli WAF de protecție pe toate planurile, inclusiv cele gratuite.

Ce recomandă DNSC

Directoratul Național de Securitate Cibernetică (DNSC) a emis o alertă pentru administratorii de site-uri din România, cu următoarele recomandări:

1. Efectuarea imediată de verificări suplimentare pentru identificarea eventualelor semne de anomalii sau de compromitere a site-urilor web.
2. Verificarea, din Dashboard, dacă actualizările automate au fost aplicate cu succes.
3. Actualizarea manuală de urgență la versiunile remediate (6.8.6, 6.9.5 sau 7.0.2), acolo unde auto-update-ul nu a funcționat.
4. Utilizarea unor unelte de scanare (de ex. wp2shell.com sau scanerul disponibil pe GitHub) pentru a verifica expunerea.
5. Ca măsură temporară, blocarea accesului anonim la /wp-json/batch/v1 prin WAF sau plugin-uri de securitate.
6. Înlocuirea versiunilor vulnerabile cu WordPress 7.0.2 sau 6.9.5 (respectiv 6.8.6 pentru ramura 6.8).

Ce trebuie să faci acum, pas cu pas

• Actualizează imediat. Verifică versiunea din Panou → Actualizări și confirmă că rulezi 6.8.6 / 6.9.5 / 7.0.2 sau mai nou. Nu presupune că auto-update-ul a rezolvat totul.
• Blochează endpoint-ul batch la nivel de WAF dacă nu poți actualiza pe loc: /wp-json/batch/v1 și ?rest_route=/batch/v1.
• Verifică semnele de compromitere: conturi de administrator noi/necunoscute, plugin-uri sau fișiere PHP neașteptate, cereri POST anormale către endpoint-ul batch în log-urile serverului.
• Rotește secretele dacă suspectezi o breșă: parole de admin, chei API, chei salt din wp-config.php, credențialele bazei de date.
• Restricționează accesul anonim la REST API ca strat suplimentar de apărare, dacă site-ul nu depinde de el pentru vizitatori nelogați.

Dacă hostingul tău oferă actualizări automate gestionate (managed WordPress) sau un firewall aplicativ inclus, verifică în panoul de administrare că protecția este activă — multe companii de găzduire au aplicat deja regulile de blocare la nivel de platformă. Vezi și furnizorii de găzduire WordPress care includ patching automat și WAF gestionat.

Notă: acest articol are scop informativ și defensiv. Detaliile tehnice sunt prezentate pentru a ajuta administratorii să înțeleagă riscul și să își protejeze site-urile, nu constituie un ghid de exploatare.