wp2shell: WordPress a peticit două găuri critice, iar atacurile au început în 90 de minute. Cum verifici dacă site-ul tău a fost deja spart

Pe 17 iulie 2026, echipa WordPress a lansat trei versiuni de securitate deodată, pentru două vulnerabilități din nucleu care, combinate, permit unui atacator neautentificat să ajungă la execuție de cod pe server. Lanțul a primit numele „wp2shell”. Prima recomandare a fost, evident, actualizarea. Problema e că aproape toată lumea s-a oprit acolo, iar asta nu e suficient: un site actualizat pe 25 iulie poate fi în continuare compromis, pentru că patch-ul închide ușa, dar nu scoate afară pe cine a intrat deja. Mai jos e ce s-a întâmplat și, mai important, cum verifici singur dacă ești printre cei intrați.

Ce s-a întâmplat pe 17 iulie 2026

Anunțul oficial de pe wordpress.org descrie două probleme: una de severitate critică și una ridicată. Prima este o injecție SQL în parametrul author__not_in din WP_Query (CVE-2026-60137), raportată de cercetătorii TF1T, dtro și haongo. A doua este o confuzie de rutare pe endpointul batch al REST API, care, înlănțuită cu injecția SQL, duce la execuție de cod la distanță (CVE-2026-63030); a fost raportată de Adam Kues, de la Assetnote și Searchlight Cyber. Echipa WordPress.org a activat și actualizări automate forțate pentru site-urile care rulau versiuni afectate.

Cronologia care contează pentru un patron nu este însă cea a anunțului, ci cea a atacatorilor:

Cine era vulnerabil, de fapt

Aici merită să fim exacți, pentru că a circulat ideea că „tot WordPress-ul” era afectat. Nu era. Situația reală, conform anunțului oficial și fișelor din baza de date națională de vulnerabilități a NIST:

• 6.8.0 până la 6.8.5: afectate doar de injecția SQL. Versiunea de reparație este 6.8.6.
• 6.9.0 până la 6.9.4 și 7.0.0 până la 7.0.1: afectate de ambele probleme, deci de lanțul complet până la execuție de cod. Versiunile de reparație sunt 6.9.5 și 7.0.2.
• Versiunile mai vechi de 6.8: neafectate de acest lanț. Ceea ce nu e o veste bună, dacă rulezi așa ceva, fiindcă înseamnă că ai altele, mai vechi, netratate.

Un detaliu pe care merită să îl reții pentru orice discuție viitoare despre severitate: scorurile publicate pentru aceleași două probleme diferă între organizații. Pentru CVE-2026-63030, WPScan, în calitate de autoritate care a atribuit identificatorul, dă 9.8 (critic), în timp ce echipa CISA-ADP dă 7.5 (ridicat), punctând doar impactul asupra confidențialității. Pentru CVE-2026-60137, raportul se inversează: 5.9 la WPScan, 9.1 la CISA-ADP. Nu este o contradicție și nici o eroare de presă, ci diferență de metodologie. Concluzia practică rămâne aceeași indiferent de scor: se peticește imediat.

Nu a fost vina unui plugin

Reflexul obișnuit, când apare o problemă la un site WordPress, este să dai vina pe pluginuri. De data asta nu se poate. Ambele vulnerabilități sunt în nucleul WordPress, în cod care rulează pe orice instalare, chiar și pe una curată, fără niciun plugin adăugat. Este exact motivul pentru care evenimentul a fost tratat mai serios decât o vulnerabilitate obișnuită de plugin, care afectează doar cine are acel plugin instalat.

„Am dat update, deci sunt bine” este concluzia scumpă

Aceasta este partea pentru care merită citit tot articolul. Actualizarea WordPress închide vulnerabilitatea, însă nu face niciunul dintre lucrurile de mai jos:

• nu șterge un webshell deja scris pe disc;
• nu elimină un cont de administrator creat de atacator;
• nu dezinstalează un plugin malițios încărcat între timp;
• nu invalidează parolele și datele care au fost deja citite din baza de date.

Nu e o interpretare a noastră. Recomandarea publică, reluată și de CERT-ul național spaniol INCIBE, a fost ca administratorii să verifice dacă au fost compromiși înainte de a aplica pur și simplu patch-ul. Iar actualizările automate forțate, oricât de utile, nu sunt o garanție individuală: pot fi dezactivate din wp-config.php sau pot eșua din cauza permisiunilor pe fișiere. O măsurătoare pe un eșantion de 124.580 de site-uri, făcută de cercetătorul Yutaka Sejiyama, arăta o rată de peticire de 81,6% la patru zile după lansare. Adică aproape unul din cinci era încă expus.

Cum verifici în douăzeci de minute dacă ai fost compromis

Următoarele verificări nu cer cunoștințe de programare și pot fi făcute de oricine are acces la panoul WordPress și la fișierele site-ului. Indicatorii vin din analizele publicate de SANS Internet Storm Center, Bitdefender și Wiz.

Dacă niciuna dintre aceste verificări nu scoate nimic la iveală și site-ul rulează o versiune reparată, ești, cu o probabilitate rezonabilă, în regulă. Dacă găsești ceva, sari direct la ultima secțiune.

Ce a blocat Cloudflare și ce nu poate bloca un filtru

În aceeași zi cu patch-ul, la 17:03 UTC, Cloudflare a pus în funcțiune două reguli gestionate, ambele cu acțiunea implicită Block: una pentru injecția SQL și una pentru execuția de cod la distanță. Regulile au fost livrate tuturor clienților, inclusiv celor de pe planul gratuit. Este exact genul de reacție pentru care merită să ai traficul trecut printr-un filtru, pentru că îți cumpără ore până apuci să actualizezi.

Tot Cloudflare scrie însă, în propriul articol, propoziția pe care preferăm să o cităm ca atare, în loc să o ocolim: protecțiile WAF reduc expunerea cât timp clienții actualizează, dar nu înlocuiesc peticirea. Iar la nivel de detaliu tehnic, tot ei precizează că actualizarea WordPress rămâne cel mai eficient mod de a rezolva problema. Trei consecințe practice pentru tine:

• Dacă înregistrarea DNS nu este proxied, nu ai nimic. Norișorul trebuie să fie portocaliu, nu gri. O înregistrare care ocolește filtrul înseamnă zero protecție, indiferent de plan.
• Blocarea unei singure căi nu ajunge. După 21 iulie, atacatorii au renunțat la forma din adresa web folosită de dovezile de concept publice. Trebuie acoperite ambele forme ale endpointului, atât /wp-json/batch/v1, cât și varianta cu parametrul rest_route.
• Un filtru nu curăță. Dacă webshell-ul e deja pe disc, atacatorul îl poate folosi pe alte căi. Filtrul oprește cererile ostile din exterior, nu consecințele unei intrări deja reușite.

Dacă vrei detaliul despre ce face și ce nu face un asemenea filtru, l-am explicat pe larg în ghidul despre ce este un WAF, iar setarea concretă pentru site-urile WordPress este descrisă în pagina noastră de securitate WordPress.

Detaliul despre Wordfence pe care merită să îl știi dinainte

Mulți patroni presupun că un plugin de securitate gratuit îi acoperă în ziua zero. Nu este cazul, și nu e o critică a produsului, ci o proprietate a modelului de livrare. Regula de firewall pentru wp2shell a plecat pe 17 iulie către clienții planurilor plătite Wordfence, iar varianta gratuită o primește după întârzierea standard de 30 de zile. Adică exact după ce trece valul. Bun de știut înainte de următorul incident, nu în timpul lui.

Dacă găsești ceva: ordinea corectă a pașilor

Presupune compromitere, nu o exclude din start. Ordinea de mai jos limitează daunele, deși trebuie spus cinstit că o curățare completă depășește, de regulă, ce poate face singur un patron într-o după-amiază.

• Nu restaura orbește dintr-o copie făcută după 17 iulie. Poate conține deja webshell-ul. Dacă nu poți stabili cu certitudine momentul intrării, opțiunile oneste sunt curățarea fișier cu fișier sau reconstruirea pe curat.
• Schimbă parolele tuturor conturilor de administrator și șterge conturile pe care nu le recunoști.
• Regenerează cheile și sărurile de autentificare din wp-config.php. Este pasul care invalidează sesiunile deschise, inclusiv ale atacatorului. Schimbă și parola bazei de date, pentru că lanțul permitea citirea ei.
• Dacă ai comenzi sau conturi de clienți, tratează situația și juridic. Termenul de notificare către autoritate este de 72 de ore de la momentul în care ai luat cunoștință, iar pașii concreți sunt în ghidul despre raportarea unui incident cibernetic.
• Dacă site-ul e vizibil compromis, curățarea efectivă a fișierelor de pe server se face cu hosterul sau cu cine îți administrează codul. Noi lucrăm la nivel de rețea și te putem ghida, iar procedura de urgență e descrisă la intervenție urgentă.

Ce pregătești pentru data viitoare

Lecția reală a acestui incident nu este despre WordPress, ci despre timp. Fereastra dintre publicarea patch-ului și primele exploatări automate a fost de aproximativ 90 de minute. Nu de o săptămână, cât își imaginează multă lume că are la dispoziție. Trei lucruri care se pregătesc din timp și costă foarte puțin:

• O alertă pe email când apare un cont de administrator nou sau un fișier PHP nou în wp-content/. Costă zero și prinde exact acest tip de atac.
• Traficul trecut printr-un filtru gestionat, cu reguli care se actualizează fără să faci tu nimic. Nu ca să eviți actualizarea, ci ca să ai ore în plus până o faci.
• Un contact la hoster despre care știi dinainte că îți dă logurile în aceeași zi. Un incident nu e momentul în care descoperi că furnizorul tău nu păstrează loguri.

Surse

Pentru cine vrea să verifice direct, acestea sunt sursele principale ale articolului:

• Anunțul oficial al versiunilor de securitate: wordpress.org.
• Fișele tehnice ale celor două vulnerabilități, în baza de date NIST: CVE-2026-63030 și CVE-2026-60137.
• Regulile WAF și precizarea că nu înlocuiesc patch-ul: blogul Cloudflare.
• Exploatarea confirmată în honeypot, cu webshell și cont de administrator nou: SANS Internet Storm Center.
• Volumul de atacuri și schimbarea formei cererilor: Patchstack. Indicatorii de compromitere: Bitdefender.

Concluzie

wp2shell a fost un caz de manual: o problemă în nucleu, un patch rapid și corect, și un val de exploatare automată care a pornit în mai puțin de două ore. Cine a actualizat în prima zi a scăpat aproape sigur. Cine a actualizat mai târziu are o întrebare deschisă la care doar o verificare răspunde, nu o presupunere. Cele cinci verificări din acest articol nu costă nimic, iar dacă nu găsesc nimic, măcar știi de ce dormi liniștit. Dacă vrei să nu mai depinzi de cât de repede apuci să reacționezi tu, exact asta facem la UpTrust: ținem filtrul actualizat în locul tău și îți spunem ce a fost oprit.