Aproape tot sfatul de securitate pentru WordPress încape într-o propoziție: ține plugin-urile la zi, pentru că acolo stau vulnerabilitățile. wp2shell sparge acest model. Lanțul de vulnerabilități, descoperit de Adam Kues de la Assetnote (Searchlight Cyber) și corectat pe 17 iulie în WordPress 6.9.5 și 7.0.2, se află în nucleul WordPress. O instalare curată, cu zero plugin-uri, este exploatabilă, iar cercetătorii descriu atacul ca neavând „nicio precondiție" — o cerere HTTP anonimă se termină cu execuție de cod pe server.
Ce știm
wp2shell înseamnă două bug-uri înlănțuite, ambele cu CVE-uri alocate: CVE-2026-63030, o confuzie de rute în endpoint-ul batch al REST API, și CVE-2026-60137, un SQL injection în nucleul WordPress. Punctul de intrare este endpoint-ul REST batch (/wp-json/batch/v1) — o funcționalitate livrată încă din versiunea 5.6 și documentată public de atunci. Înlănțuite, cele două duc o cerere anonimă până la execuție de cod la distanță.
Intervalele afectate sunt 6.9.0–6.9.4 (corectat în 6.9.5) și 7.0.0–7.0.1 (corectat în 7.0.2). Codul vulnerabil există doar începând cu 6.9 — lansată în decembrie 2025 — deci nu vorbim de un bug vechi de un deceniu, dar 6.9 și 7.0 sunt exact versiunile pe care rulează site-urile bine întreținute. WordPress a considerat situația suficient de gravă încât să activeze actualizări forțate prin sistemul de auto-update, o măsură rezervată celor mai grave cazuri.
De la publicare, lucrurile s-au mișcat repede: mecanismul complet a fost făcut public, iar pe GitHub există deja un proof-of-concept funcțional. Fereastra dintre „patch disponibil" și „exploit disponibil" — singurul avans pe care îl aveau apărătorii — s-a închis deja.
De ce contează dincolo de site-ul de prezentare
E tentant să pui problemele WordPress la categoria „treaba celor de la marketing". Nu o face. În majoritatea organizațiilor, WordPress rulează site-ul companiei, pagina de cariere, câteva landing page-uri, poate un intranet — de multe ori pe infrastructură care împarte DNS, certificate TLS, credențiale sau contul de hosting cu lucruri mult mai importante. Execuția de cod pe acel server este un punct de sprijin: suficient pentru phishing către clienții tăi de pe propriul tău domeniu, otrăvirea SEO, furtul datelor din formulare sau mișcare laterală mai departe.
Există și precedent pentru ce urmează. Gruparea WP-SHELLSTORM a compromis peste 17.000 de site-uri printr-o singură vulnerabilitate de plugin de caching — una deja publică și deja corectată. Exploatarea în masă a WordPress este o industrie; un RCE pre-autentificare în core, cu PoC public, este materia ei primă ideală.
Ce verifici azi
- Verifică versiunea care rulează efectiv. WordPress a împins actualizări forțate, dar nu a confirmat dacă acestea ajung și la site-urile care au dezactivat auto-update. Nu presupune că patch-ul a ajuns — verifică. Inclusiv clonele de staging, instalările uitate pe subdomenii și tot ce administrează o agenție pentru tine.
- Dacă nu poți actualiza imediat, blochează accesul anonim la endpoint-ul batch — și blochează ambele rute:
/wp-json/batch/v1și varianta cu query stringrest_route=/batch/v1. O regulă WAF care acoperă doar prima cale o lasă deschisă pe a doua. Dezactivarea REST API pentru utilizatori neautentificați sau plugin-ul minimal publicat de cercetători sunt alternative temporare.
- Caută în loguri trafic către
batch/v1. Cererile către endpoint-ul batch venite din surse neautentificate — mai ales după 17 iulie — merită o privire. Cu un PoC public, scanarea este o chestiune de „când", nu de „dacă".
- Fă inventarul instalărilor WordPress. Cele mai multe organizații pățite cu WordPress au fost compromise prin instalarea de care uitaseră. Dacă nu poți enumera în cinci minute toate instanțele WordPress de pe domeniile tale, acesta este primul finding.
Lecția mai mare: „core-ul e sigur" era o presupunere, nu un fapt
Orice stack web cară presupuneri pe care nu le testează nimeni: core-ul e auditat, REST API-ul e inofensiv, endpoint-ul acela cere autentificare. wp2shell — la fel ca SQL injection-ul anonim din nucleul Drupal, din acest an — ne amintește că aceste presupuneri au termen de valabilitate. Exact aici își arată valoarea un test de penetrare pentru aplicații web: nu doar un scanner trecut peste plugin-uri, ci verificarea suprafeței REST, a granițelor de autentificare și a presupunerilor de sub CMS — inclusiv pentru instalările uitate. Împreună cu o evaluare de vulnerabilități recurentă, obții și inventarul care transformă „suntem afectați?" dintr-o alarmă generală într-o simplă căutare.
Dacă WordPress există undeva în organizația ta — chiar și „doar site-ul" — și nu ești sigur că fiecare instanță e actualizată și fiecare endpoint batch e închis, scrie-ne. Verificarea durează mult mai puțin decât curățenia de după.
Acest articol este informare generală bazată pe raportări publice ale WordPress.org, Searchlight Cyber/Assetnote și The Hacker News, nu consultanță de răspuns la incidente pentru un mediu specific.