Noi vulnerabilități în WordPress permit 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, o condiție pentru cache-ul persistent a fost descoperită, iar o dovadă de concept funcțională este acum publică. Povestea de mai jos reflectă toate detaliile, conform thehackernews.com.
👉 Descrierea vulnerabilităților și patch-urile lansate
O solicitare HTTP anonimă poate executa cod pe un site WordPress. Bugul se află în nucleul sistemului, astfel că o instalație curată, fără plugin-uri, este exploatabilă. Fiecare site pe versiunile 6.9 și 7.0 a fost vulnerabil până vineri, când WordPress a lansat versiunile 6.9.5 și 7.0.2, activând ceea ce numește actualizări forțate prin sistemul său de actualizare automată. wp2shell cuprinde două erori, nu una, și ambele au acum ID-uri CVE. CVE-2026-63030 este confuzia în ruta batch a REST API; CVE-2026-60137 este o injecție SQL în nucleul WordPress. Asemenea, ele permit unei solicitări anonime să ajungă la execuția de cod.
De vineri, mecanismul complet a fost publicat, iar o dovadă de concept funcțională a fost urcată pe GitHub. Adam Kues de la Assetnote, ramura de gestionare a suprafeței de atac a Searchlight Cyber, a descoperit bugul din ruta batch și l-a raportat prin programul HackerOne al WordPress. Descrierea, publicată sub numele de 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ă scrierea tehnică și le recomandă proprietarilor un instrument de verificare la wp2shell.com.
👉 Detalii tehnice ale vulnerabilităților și recomandări
Reținerea acestei informații nu este acum relevantă: patch-ul este public, iar alți cercetători l-au citit. Cele două buguri nu afectează aceleași versiuni, iar aceasta este cheia pentru a determina cine este expus la ce. Injecția datează din versiunea 6.8. Confuzia rutei batch, partea care transformă o injecție limitată într-o execuție de cod neautentificată, există doar de la 6.9 încolo. Beta 7.1 include ambele fixuri. Un site pe versiunea 6.8 nu este exploatabil pentru execuție de cod prin această conexiune, motiv pentru care 6.8.6 repară doar injecția. WordPress nu a precizat dacă actualizările forțate ajung la site-urile care au dezactivat actualizările automate. Verificați ce rulați de fapt, mai degrabă decât să presupuneți că a fost implementată.
Postarea Searchlight estimează că peste 500 de milioane de site-uri folosește WordPress. Această cifră reprezintă întreaga bază de instalare, nu setul expus: lanțul de execuție de cod există doar de la 6.9, care a fost lansat pe 2 decembrie 2025. Așadar, fiecare site expus căii de execuție a codului rulează o versiune mai veche de opt luni, iar niciun anunț nu indică câte sunt acestea.
Lanțul are două mici greșeli. Injecția se află în parametrul author__not_in al WP_Query: dacă îi oferiți un șir în loc de un tablou, verificarea care se așteaptă la un tablou este omisă, lăsând valoarea brută să fie folosită în interogare. Accesul la acel parametru fără autentificare este responsabilitatea punctului final batch. Ruta /wp-json/batch/v1 a WordPress rulează mai multe sub-solicitări într-o singură apelare și le urmărește în două tablouri paralele; o eroare într-o sub-solicitare decoordează tablourile cu unul, astfel că o solicitare rulează sub handler-ul unei alte solicitări. Nesting-ul, această confuzie trece peste lista de permisiuni a punctului final și permite input-ul atacatorului să ajungă în interogarea vulnerabilă, fără autentificare.
Punctul final batch este disponibil din versiunea 5.6 din 2020; confuzia care îl abuzează este nouă, de la 6.9. Scorurile merită să fie citite cu atenție. Anunțul propriu al WordPress evaluează lanțul RCE ca fiind critic. Înregistrarea sa CVE îi acordă un scor de 7.5, considerat doar înalt, iar metricile de impact creditează doar accesul la date, nu pierderile de integritate sau disponibilitate pe care le-ai aștepta de la execuția de cod. Injecția depinde de scoruri mai mari de 9.1, critic. Bugul pe care toată lumea îl numește RCE critic este, conform propriului său număr, mai puțin grav, deoarece scorul recompensează acoperirea directă a injecției în baza de date, tratând confuzia rutei pe cont propriu ca pe o eroare de analiză. Urmăriți ambele CVE-uri, nu eticheta oricărei erori.
O condiție reduce raza de impact. Calea de execuție a codului funcționează doar când site-ul nu rulează un cache de obiecte persistent, conform Cloudflare, care a livrat reguli WAF odată cu dezvăluirea. O instalare implicită nu are un astfel de cache, astfel că expunerea rămâne pentru instalațiile implicite. Un site care rulează WordPress cu Redis sau Memcached ca cache de obiecte persistent ar putea să nu fie pe acest anumit drum, dar aceasta este o consecință secundară, nu o soluție, și nu acoperă injecția SQL.
Cu ID-uri CVE atribuite, scanerele pot în sfârșit să o observe: Rapid7 anunță că verificările autentificate pentru InsightVM și Nexpose apar pe 20 iulie. Nu este pe catalogul KEV al CISA, care necesită exploatarea confirmată, iar nicio exploatare nu a fost raportată până pe 18 iulie. Acest confort este mai subțire decât pare. Exploatarea în masă a WordPress este acum o industrie. Înainte ca serverul să iasă la iveală în iunie, o singură vulnerabilitate într-un plugin de cache a permis echipei WP-SHELLSTORM să acceseze mai mult de 17.000 de site-uri, conform propriei lor numărători, folosind un bug care era deja public, deja reparat și care funcționa doar pe o setare non-implicită. Aceasta este publică, reparată și funcționează pe setarea implicită. Fiecare măsură de prevenire pe care o oferă Searchlight se reduce la menținerea apelurilor anonime departe de punctul final batch. Toate sunt soluții temporare până când veți actualiza și toate pot perturba integrările legitime: nucleul WordPress este open source, iar versiunea menționează fișierele pe care le-a schimbat. Acesta a fost întotdeauna suficient.
Searchlight a păstrat scrierea sa; în termen de o zi, alți cercetători au citit patch-ul, au publicat mecanismul și au pus un exploit pe GitHub, ceea ce este forma exactă în care dezvăluirea a ajuns la destinație. Nu poți livra o soluție fără a livra și harta către bug. Singura opțiune rămasă este cât de repede ajunge patch-ul la site-uri înainte ca cineva să-l citească, iar WordPress s-a mișcat rapid vineri. Acum, exploit-ul este public, iar actualizarea este încă în curs. Statisticile versiunii WordPress vor arăta câte site-uri au primit patch-ul; traficul de scanare împotriva batch/v1 va arăta câți atacatori au venit în căutare. Orice ar fi, curba care este mai abruptă va decide cum va fi amintită această situație.