Pe 17 iulie 2026, echipa WordPress a lansat de urgență trei versiuni de securitate — 7.0.2, 6.9.5 și 6.8.6 — și a activat actualizări automate forțate la nivel global. Motivul: o vulnerabilitate botezată „wp2shell”, care permite unui atacator neautentificat să execute cod pe o instalație WordPress standard, fără niciun plugin instalat și fără nicio interacțiune din partea unui utilizator real.
E genul de vulnerabilitate care apare rar — nu pentru că e sofisticată tehnic, ci pentru că nu cere absolut nimic din partea victimei. Nu trebuie păcălit un utilizator, nu trebuie ghicită o parolă, nu trebuie exploatat un plugin terț. O instalație WordPress complet standard, fără nimic instalat suplimentar, e vulnerabilă.
Ce este, de fapt, wp2shell
Numele sugerează o singură breșă. În realitate, wp2shell combină două vulnerabilități separate din nucleul WordPress, care independent ar fi limitate, dar împreună devin periculoase.
Prima componentă (CVE-2026-63030) e o problemă de „confuzie de rută” în API-ul REST pentru procesare în lot (batch), introdus în WordPress 6.9 pentru a permite trimiterea mai multor cereri într-un singur apel API, din motive de performanță. Din cauza unei erori de logică, această cale permite ocolirea verificării de autorizare care ar trebui, în mod normal, să blocheze accesul neautentificat.
A doua componentă (CVE-2026-60137) e o vulnerabilitate de tip SQL injection într-un parametru al clasei WP_Query — nucleul din spatele aproape oricărei interogări de bază de date pe care o face WordPress. Ca vulnerabilitate izolată, ar necesita un cont autentificat pentru exploatare.
Combinate, prima vulnerabilitate permite ocolirea completă a autentificării necesare pentru a exploata a doua. Rezultatul: un atacator anonim poate extrage date din baza de date — inclusiv hash-ul parolei de administrator — și poate prelua controlul complet al site-ului, de obicei prin plasarea unui webshell (un fișier malițios care oferă acces persistent și control asupra serverului).
Ce versiuni sunt afectate
Verifică exact versiunea instalată — nu presupune că actualizarea automată forțată a funcționat, pentru că acest mecanism nu ajunge la instalările care au actualizările automate dezactivate sau blocate manual.
Afectate de lanțul complet de exploatare: WordPress 7.0.0 până la 7.0.1, și 6.9.0 până la 6.9.4.
Afectate parțial (doar vulnerabilitatea SQL injection, fără ocolirea de autentificare): WordPress 6.8.0 până la 6.8.5.
Corectate: 7.0.2, 6.9.5, 6.8.6 și orice versiune ulterioară.
Neafectate: versiuni anterioare lui 6.8.
Cum verifici versiunea reală instalată
Cea mai sigură metodă e din panoul de administrare WordPress, secțiunea Actualizări, care afișează explicit versiunea curentă. Alternativ, pentru cineva cu acces la server, comanda `wp core version` (dacă ai WP-CLI instalat) confirmă instant versiunea, per fiecare site în parte — esențial dacă administrezi mai multe instalări WordPress, nu doar una.
Verificarea prin codul sursă al paginii (căutarea etichetei „generator” din meta tag-uri) e mai puțin fiabilă, pentru că multe site-uri securizate corect ascund intenționat această informație — exact genul de măsură pe care o recomandăm și noi în mod normal, dar care în acest caz specific face verificarea rapidă puțin mai greoaie.
Un detaliu tehnic important: cache-ul de obiecte
Cercetătorii de la Cloudflare au raportat că prima componentă a vulnerabilității (confuzia de rută) e accesibilă în special atunci când site-ul nu folosește un cache de obiecte persistent (Redis sau Memcached). Site-urile cu un asemenea cache activ ar putea să nu expună aceeași cale de atac — dar asta nu înseamnă că sunt complet în siguranță, pentru că vulnerabilitatea de SQL injection rămâne prezentă indiferent de configurarea cache-ului. Nu trata absența cache-ului de obiecte ca pe o scuză pentru a amâna actualizarea — tratează-l cel mult ca un factor care influențează urgența relativă, nu ca o exceptare.
De ce contează cronologia acestei breșe
Patch-ul a fost lansat vineri seara, ora Europei — moment cunoscut pentru a lăsa echipele de securitate să gestioneze eventuale probleme peste weekend, cu resurse reduse. În câteva ore de la publicarea patch-ului, au apărut primele semnale de exploatare activă, iar cod funcțional de exploatare (proof-of-concept) a devenit public în aceeași noapte. Mai multe firme de securitate au confirmat ulterior exploatare activă în teren, cu atacatori care instalează webshell-uri persistente pe serverele vulnerabile.
Lecția practică din această cronologie: dacă aștepți un semnal „oficial” clar — o listare într-un catalog guvernamental de vulnerabilități cunoscute, de exemplu — poți pierde zile întregi în care exploatarea activă e deja în desfășurare, deși informația despre patch și severitate era deja publică de la ora lansării.
Ce faci dacă ai găsit o versiune vulnerabilă
Actualizează imediat la 7.0.2, 6.9.5 sau 6.8.6, în funcție de ramura pe care rulează site-ul. Nu aștepta o fereastră de mentenanță programată — pentru o vulnerabilitate din această categorie, actualizarea e o urgență imediată, nu o sarcină de rutină.
Dacă din motive tehnice nu poți actualiza imediat pe toate instalările, o soluție temporară e blocarea accesului la endpoint-ul vulnerabil printr-o regulă de server, având grijă să acoperi ambele variante de acces posibile ale acelei rute API — o greșeală frecventă e blocarea unei singure variante de URL, lăsând cealaltă complet deschisă. O asemenea măsură reduce temporar expunerea, dar nu înlocuiește actualizarea reală — cumpără timp, nu rezolvă vulnerabilitatea.
Actualizarea nu e ultimul pas — verifică dacă ai fost deja compromis
Aplicarea patch-ului închide ușa, dar nu îți spune nimic despre ce s-a întâmplat înainte de asta. Dacă site-ul tău a rulat o versiune vulnerabilă în perioada de expunere (mai ales în orele și zilele imediat după publicarea patch-ului, când exploatarea activă era deja confirmată), merită o verificare activă pentru semne de compromitere:
Conturi de administrator noi sau neexplicate. Verifică lista completă de utilizatori cu rol de administrator — orice cont pe care nu-l recunoști, sau orice cont existent cu privilegii escaladate fără explicație, e un semnal de alarmă.
Plugin-uri sau fișiere necunoscute. Caută în special fișiere PHP recent create în directoarele de upload — o locație în care, în mod normal, nu ar trebui să existe fișiere executabile.
Înregistrări neobișnuite în baza de date. Verifică pentru rânduri anormale în tabelele de articole sau opțiuni ale WordPress.
Jurnalele serverului. Verifică cererile către endpoint-ul vulnerabil din jurnalele de acces ale serverului, pentru perioada de expunere.
Dacă găsești orice semn de compromitere, tratează parola de administrator ca fiind deja expusă — schimb-o, invalidează toate sesiunile active, și regenerează cheile de securitate (salts) din configurarea WordPress. Dacă există indicii clare că un webshell a fost plasat, o reinstalare completă dintr-o sursă curată, urmată de restaurarea conținutului dintr-un backup dinainte de perioada de expunere, e soluția mai sigură decât o „curățare” manuală, care riscă să lase ceva neobservat.
Cronologia completă a evenimentelor
Pentru cine vrea să înțeleagă exact cât de repede s-a desfășurat totul:
Vineri, 17 iulie, seara (ora Europei): WordPress lansează versiunile 7.0.2, 6.9.5 și 6.8.6, activează actualizările automate forțate, și publică avizele oficiale de securitate cu detalii despre ambele vulnerabilități.
Aceeași seară, la scurt timp după lansare: Cloudflare implementează reguli de firewall dedicate pentru a bloca tentativele de exploatare la nivel de rețea, pentru clienții care folosesc serviciul.
Sâmbătă, în primele ore ale dimineții: apar primele semnale de exploatare activă, iar cod funcțional de exploatare (proof-of-concept) devine public.
Sâmbătă, mai târziu: mai multe firme de securitate confirmă independent exploatarea activă, cu evaluări ușor diferite despre amploarea reală a atacurilor.
Luni, 20 iulie: autorități naționale de securitate cibernetică din mai multe țări publică alerte oficiale despre vulnerabilitate.
Marți, 21 iulie: vulnerabilitatea e adăugată în cataloage internaționale de vulnerabilități exploatate activ — la câteva zile bune după ce exploatarea reală era deja confirmată de cercetători independenți.
Diferența dintre momentul patch-ului (vineri seară) și momentul recunoașterii „oficiale” complete (marți) ilustrează exact riscul discutat mai sus: cine aștepta un semnal oficial clar a rămas expus zile întregi, deși informația necesară pentru a acționa era deja disponibilă public de la bun început.
Întrebări frecvente despre wp2shell
Site-ul meu e vulnerabil? Dacă rulează WordPress 6.9.0 până la 6.9.4 sau 7.0.0 până la 7.0.1, ești expus lanțului complet de exploatare. Pe 6.8.0 până la 6.8.5, se aplică doar componenta de SQL injection, fără ocolirea completă a autentificării. Versiunile 6.9.5, 7.0.2, 6.8.6 și ulterioare sunt corectate.
Actualizările automate forțate nu m-au protejat deja? Probabil da, dar nu sigur. Mecanismul nu ajunge la instalările care au dezactivat sau blocat actualizările automate, din diverse motive tehnice sau de configurare. Verifică explicit versiunea reală, nu presupune.
Am nevoie de un plugin anume ca să fiu expus? Nu. O instalație complet standard, fără niciun plugin suplimentar, fără nicio configurare specială și fără niciun cont valid, e vulnerabilă prin simpla prezență a nucleului WordPress neactualizat.
Un firewall aplicativ (WAF) e suficient, fără actualizare? Nu. Blocarea la nivel de firewall cumpără timp, nu rezolvă vulnerabilitatea reală din cod. În plus, o regulă de blocare incompletă, care acoperă doar una dintre cele două variante de acces posibile ale endpoint-ului vulnerabil, lasă practic ușa la fel de deschisă.
Am aplicat patch-ul. Mai am ceva de făcut? Da. Un patch aplicat azi nu spune nimic despre ce s-a întâmplat înainte de aplicarea lui. Verifică activ pentru conturi de administrator noi, fișiere neobișnuite, și cereri suspecte în jurnalele serverului, mai ales dacă site-ul a rulat o versiune vulnerabilă în perioada de exploatare activă confirmată.
Ce fac dacă găsesc semne de compromitere? Tratează parola de administrator ca deja expusă — schimb-o, invalidează sesiunile active, regenerează cheile de securitate. Dacă există indicii clare ale unui webshell plasat, o reinstalare completă dintr-o sursă curată, cu restaurare de backup dinainte de perioada de expunere, e mai sigură decât o curățare manuală parțială.
Ce ne învață episodul ăsta, dincolo de patch-ul în sine
Cel mai relevant aspect al acestei breșe nu e complexitatea tehnică — e viteza. Într-un interval de câteva ore de la publicarea unui patch, informația necesară pentru exploatare a devenit publică, iar atacatorii au acționat mult mai rapid decât mulți administratori de site-uri au apucat să reacționeze. Un proces de monitorizare care depinde exclusiv de liste centralizate „oficiale” de vulnerabilități cunoscute, verificate ocazional, nu ține pasul cu o amenințare care se mișcă în ore, nu în zile.
Exact de aceea monitorizarea activă și actualizările aplicate prompt — nu atunci când există timp, ci prioritizate real — fac diferența reală între un site care rămâne neatins și unul care ajunge o statistică într-un raport de securitate.
De ce contează că vulnerabilitatea a fost în nucleu, nu într-un plugin
Majoritatea vulnerabilităților critice pe care le vedem în mod obișnuit provin din plugin-uri sau teme terțe — cod scris de dezvoltatori diverși, cu niveluri variate de rigoare în privința securității. Nucleul WordPress, în schimb, e mult mai atent revizuit, testat și auditat, tocmai pentru că rulează pe procente uriașe din tot internetul. O vulnerabilitate critică descoperită direct acolo, care nu cere niciun plugin pentru a fi exploatabilă, are o rază de impact fundamental diferită — nu afectează doar site-urile care au ales să instaleze un anumit plugin nesigur, ci potențial orice instalație WordPress standard, indiferent cât de minimalist configurată.
Asta explică și de ce echipa WordPress a ales să activeze actualizări automate forțate, o măsură rar folosită, rezervată exact pentru situații în care viteza de răspuns contează mai mult decât riscul teoretic ca o actualizare automată să creeze o incompatibilitate neașteptată. Compromisul a fost calculat corect: riscul unei incompatibilități minore e mult mai mic decât riscul unei execuții de cod la distanță, neautentificate, pe milioane de site-uri.
Cum alegi un partener care prinde astfel de urgențe la timp
Dacă acest episod ridică o întrebare firească — „cine ar fi observat asta pentru site-ul meu, și cât de repede?” — merită să verifici explicit, la orice furnizor de administrare WordPress, cum funcționează procesul lor de reacție la vulnerabilități critice. Câteva întrebări utile de pus: monitorizează activ anunțurile directe ale echipei WordPress, sau doar cataloage centralizate care, așa cum am văzut, pot întârzia zile întregi? Există un proces de urgență separat de fereastra standard de mentenanță lunară? Cine verifică, activ, dacă actualizările automate au reușit cu adevărat, pe fiecare instalare în parte?
Răspunsurile la aceste întrebări fac diferența reală între un furnizor care aplică actualizări o dată pe lună, la o dată fixă, și unul care tratează o vulnerabilitate critică exact așa cum merită tratată — ca pe o urgență reală, rezolvată în ore, nu în săptămâni.
Ce facem noi pentru clienții noștri în astfel de situații
Pentru toate site-urile din pachetele noastre de administrare, o vulnerabilitate critică de acest calibru declanșează verificare și actualizare imediată, nu așteaptă fereastra standard de mentenanță. Monitorizăm activ anunțurile de securitate directe ale echipei WordPress, nu doar cataloagele centralizate care, așa cum am văzut în acest caz, pot întârzia semnificativ față de momentul real al expunerii.
Dacă nu ești sigur ce versiune WordPress rulează pe site-ul tău chiar acum, sau dacă a fost aplicată corect actualizarea de urgență din 17 iulie, cere un audit gratuit — verificăm imediat, fără obligații. Pentru administrare continuă, care prinde din timp exact genul de urgențe ca aceasta, vezi pachetele noastre, de la 49 €/lună.