WordPress 7.0.2 repară vulnerabilități exploatate activ: ce trebuie verificat acum

Centrul Canadian pentru Securitate Cibernetică a publicat pe 20 iulie 2026 o alertă pentru două vulnerabilități din WordPress, CVE-2026-60137 și CVE-2026-63030, despre care raportările publice indică exploatare activă. WordPress a lansat deja versiunile corectate 7.0.2, 6.9.5 și 6.8.6 și recomandă actualizarea imediată. Pentru organizațiile care folosesc WordPress, prioritatea nu este doar instalarea update-ului, ci și verificarea faptului că site-ul nu a fost deja compromis.

Ce vulnerabilități au fost corectate

Prima problemă, CVE-2026-60137, este o vulnerabilitate de tip SQL injection în parametrul author__not_in al WP_Query. A doua, CVE-2026-63030, afectează procesarea rutelor batch din REST API și, combinată cu problema SQL injection, poate conduce la execuție de cod de la distanță în WordPress 6.9 și versiunile ulterioare afectate. Advisory-ul WordPress clasifică al doilea lanț drept critic.

• WordPress 7.0.0–7.0.1: afectat de ambele vulnerabilități; versiunea corectată este 7.0.2.
• WordPress 6.9.0–6.9.4: afectat de ambele vulnerabilități; versiunea corectată este 6.9.5.
• WordPress 6.8.0–6.8.5: afectat de CVE-2026-60137; versiunea corectată este 6.8.6.
• WordPress 7.1 beta: actualizarea de securitate este 7.1 beta2.
• Potrivit WordPress, versiunile anterioare seriei 6.8 nu sunt afectate de aceste două probleme.

De ce patching-ul singur nu închide incidentul

Atunci când există indicii de exploatare activă, instalarea patch-ului reduce expunerea viitoare, dar nu elimină eventualele modificări realizate anterior de un atacator. Un cont nou de administrator, un plugin modificat, o sarcină programată sau un fișier PHP adăugat poate menține accesul chiar după actualizare. De aceea, actualizarea și verificarea post-compromitere sunt două activități distincte.

Checklist urgent pentru administratorii WordPress

• Inventariază toate instanțele WordPress, inclusiv site-uri vechi, staging, campanii și subdomenii care nu mai sunt promovate.
• Confirmă versiunea WordPress și actualizează la 7.0.2, 6.9.5 sau 6.8.6, după ramura folosită; testează înainte acolo unde procesul operațional o cere.
• Realizează un backup verificabil înainte de intervenție și păstrează logurile relevante separat de serverul analizat.
• Revizuiește conturile cu privilegii, pluginurile, temele, fișierele recent modificate și task-urile programate pentru schimbări neautorizate.
• Analizează logurile web și de autentificare pentru solicitări neobișnuite către REST API, erori SQL, uploaduri sau execuții suspecte.
• Rotește credențialele și cheile numai în cadrul unui răspuns coordonat, mai ales dacă există semne că serverul a fost compromis.
• Izolează instanța și implică echipa de incident response dacă apar indicatori de acces neautorizat; evită să distrugi probele înainte de colectare.

Ce trebuie să știe managementul

WordPress a activat actualizări forțate prin mecanismul automat pentru site-urile afectate, dar organizațiile nu ar trebui să presupună că toate instanțele au primit update-ul. Configurațiile, permisiunile, blocajele de rețea sau procesele de hosting pot produce excepții. Managementul are nevoie de un răspuns simplu și verificabil: câte instanțe există, câte erau vulnerabile, câte au fost actualizate și dacă a fost identificată activitate suspectă.

Lecția de awareness: urgența trebuie verificată, nu ignorată

Campaniile de phishing folosesc frecvent alerte reale pentru a trimite linkuri false de „actualizare urgentă”. Administratorii trebuie să pornească update-ul din consola cunoscută, din procesul de management aprobat sau din sursa oficială WordPress, nu dintr-un link primit într-un mesaj neașteptat. Awareness-ul ajută echipele să recunoască acest tip de manipulare, însă remedierea vulnerabilității și investigația tehnică trebuie executate de personal calificat.