Nouă vulnerabilitate wp2shell în WordPress permite atacatorilor neautentificați să execute cod

Actualizat pe 18 iulie 2026: cele două vulnerabilități au acum ID-uri CVE, mecanismul complet a fost publicat, a apărut o condiție de cache pentru obiecte persistente, iar un demonstrator funcțional este disponibil public. Potrivit thehackernews.com, povestea de mai jos reflectă toate acestea. O cerere HTTP anonimă poate executa cod pe un site WordPress.

👉 Descrierea vulnerabilității și identificarea bugurilor în nucleul WordPress

Bugul se află în nucleu, astfel că o instalare curată, fără pluginuri, este exploatabilă. Orice site pe versiunea 6.9 și 7.0 a fost vulnerabil până vineri, când WordPress a lansat versiunile 6.9.5 și 7.0.2 și a activat ceea ce numește actualizări forțate prin sistemul său de actualizare automată. wp2shell constă în două buguri, nu unul singur, iar ambele poartă acum ID-uri CVE. CVE-2026-63030 se referă la confuzia rutei API REST; CVE-2026-60137 este o injecție SQL în nucleul WordPress. Combinate, acestea permit unei cereri anonime să ajungă la executarea codului.

De vineri, mecanismul complet a fost publicat, iar un demonstrator funcțional a fost încărcat pe GitHub. Adam Kues de la Assetnote, ramura de gestionare a suprafeței de atac a Searchlight Cyber, a descoperit bugul rutei batch și l-a raportat prin programul HackerOne al WordPress. Descrierea, publicată sub numele wp2shell, afirmă că atacul „nu are precondiții și poate fi exploatat de un utilizator anonim”. Injecția SQL a fost raportată separat de TF1T, dtro și haongo. Searchlight își păstrează în continuare scrierea tehnică și a indicat proprietarilor un instrument de verificare la wp2shell.com.

👉 Impactul vulnerabilității și măsurile de atenuare existente

Reținerea informațiilor este acum irelevantă: patch-ul este public, iar alți cercetători l-au studiat. Cele două buguri nu ating aceleași versiuni, iar aceasta este cheia pentru a determina cine este expus la ce. Injecția se întoarce la versiunea 6.8. Confuzia rutei batch, partea care transformă o injecție limitată într-o executare de cod neautentificată, există doar din versiunea 6.9. Versiunea 7.1 beta2 conține ambele remedii. Un site pe versiunea 6.8 nu este exploatabil pentru RCE prin această lanț, motiv pentru care versiunile 6.8.6 remediază doar injecția.

WordPress nu a indicat dacă actualizarea forțată ajunge la site-urile care au dezactivat actualizările automate. Verificați ce versiune utilizați în loc să presupuneți că s-a realizat actualizarea. Postarea de la Searchlight estimează că peste 500 de milioane de site-uri utilizează WordPress. Aceasta cifră reprezintă baza totală de instalare, nu setul expus: lanțul RCE există doar din versiunea 6.9, care a fost lansată pe 2 decembrie 2025. Astfel, fiecare site expus pe căile de executare a codului rulează o versiune mai veche de opt luni, iar niciun avertisment nu precizează câte sunt.

Lanțul are două greșeli mici. Injecția se află în parametrul author__not_in din WP_Query: oferindu-i un șir în loc de un array, verificarea care se așteaptă să fie un array este sărită, introducând valoarea brută în interogare. Atingerea acelui parametru fără un login este responsabilitatea punctului final batch. Ruta /wp-json/batch/v1 a WordPress rulează mai multe subcereri într-o singură apelare și le urmărește în două array-uri paralele; o eroare într-o subcerere face ca array-urile să nu mai fie sincronizate, astfel că o cerere rulează sub handlerul unei alte cereri. Neliniaritatea aceasta ocolește lista de permisiuni a punctului final și introduce input-ul atacatorului în interogarea vulnerabilă, neautentificat. Punctul final batch a fost disponibil din versiunea 5.6 din 2020; confuzia care abuzează de el este nouă în 6.9.

Scorurile merită citite cu atenție. Avertizarea proprie a WordPress evaluează lanțul RCE drept Critic. Înregistrarea sa CVE îi oferă un scor de 7.5, considerat doar Ridicat, iar metricile de impact creditează doar accesul la date, nu și pierderile de integritate sau disponibilitate așteptate în urma executării codului. Injecția depinde de punctaje mai mari de 9.1, Critică. Bugul pe care toată lumea îl numește un RCE critic este, conform propriei sale evaluări, cel mai puțin sever dintre cele două, deoarece scorul recompensează accesul direct al injecției în baza de date și tratează confuzia rutei ca pe o eroare de analiză.

Urmăriți ambele CVE-uri, nu eticheta fiecăruia. O condiție îngustează raza de acțiune. Calea de execuție a codului funcționează doar atunci când site-ul nu utilizează un cache de obiecte persistente, conform Cloudflare, care a livrat reguli WAF împreună cu dezvăluirea. O instalare implicită nu are un asemenea cache, deci expunerea pentru instalările implicite rămâne. Un site WordPress care utilizează Redis sau Memcached ca cache de obiecte persistente ar putea fi scutit de această cale particulară, dar aceasta este un efect secundar, nu o remediere, și nu acoperă injecția SQL.

Cu ID-urile CVE atribuite, scannerele le pot observa în sfârșit: Rapid7 anunță că verificările autentificate pentru InsightVM și Nexpose vor fi disponibile pe 20 iulie. Nu se află în catalogul KEV al CISA, care necesită confirmarea exploatării, iar până la data de 18 iulie, niciuna nu a fost raportată. Această liniște este mai subțire decât pare. Exploatarea masivă a WordPress-ului este acum o industrie. Înainte ca serverul său să fi fost compromis în iunie, o singură vulnerabilitate a unui plugin de caching a permis echipei WP-SHELLSTORM să acceseze peste 17.000 de site-uri, de către propria lor numărătoare, folosind un bug care era deja public, deja reparat și care funcționa numai cu o setare non-implicită. Această vulnerabilitate este publică, reparată și funcționează cu setările implicite.

Toate măsurile de atenuare pe care le oferă Searchlight se reduc la menținerea apelanților anonimi departe de punctul final batch. Toate sunt soluții temporare până când veți actualiza, iar toate pot afecta integrările legitime: nucleul WordPress este open source, iar release-ul denumește fișierele pe care le-a schimbat. Acesta era întotdeauna destul de suficient. Searchlight a păstrat scrierea sa; în decurs de o zi, alți cercetători au citit patch-ul, au publicat mecanismul și au folosit un exploit pe GitHub, ceea ce reprezintă exact ritmul dezvăluirii. Nu poți oferi fixul fără a oferi și harta către bug. Singura pârghie rămasă este cât de repede ajunge patch-ul la site-uri înainte ca cineva să-l citească, iar WordPress a făcut acest lucru intens vineri. Acum, exploit-ul este public, iar actualizarea este încă în desfășurare. Statisticile de versiune WordPress vor arăta câte site-uri au aplicat patch-ul; traficul de scanare împotriva batch/v1 va arăta câți atacatori au venit să caute. Oricare curbă este mai abruptă va decide cum va fi amintit acest incident.