XSS2Shell: WordPress 7.0.3 repară un XSS pre-auth pe login

Ce e afectat și ce faci în următoarele minute

Dacă administrezi un WordPress, verificarea versiunii durează treizeci de secunde și e singurul lucru din acest articol care chiar contează astăzi.

• ▸Afectate: toate versiunile WordPress până la 7.0.2 inclusiv
• ▸Reparat în: 7.0.3, lansat pe 6 august 2026
• ▸Retroportat: până pe ramura 4.7
• ▸Instalările mai vechi de 4.7 rămân afectate și în afara intervalului de retroportare
• ▸Actualizările automate de fundal ar trebui să livreze patch-ul singure — verifică, nu presupune

• ▸WordPress — anunțuri de lansare

Bug-ul: doi parseri care nu sunt de acord

Când încerci să te loghezi cu un utilizator inexistent, WordPress îți afișează un mesaj de eroare care conține numele introdus. Numele trece întâi prin sanitize_user() și wp_strip_all_tags(), care se bazează pe funcția strip_tags() din PHP.

Trucul e un spațiu. Un șir care arată a etichetă HTML, dar are un spațiu imediat după paranteza unghiulară de deschidere, nu e recunoscut de strip_tags() ca etichetă — deci trece nevătămat, ca text simplu.

Mai târziu, același text ajunge la wp_kses_post(), care îl interpretează ca HTML permis. Rezultatul: elemente DOM controlate de atacator, vii, pe pagina de login.

Asta e o clasă de vulnerabilitate care merită înțeleasă dincolo de acest caz: nu e „cineva a uitat să sanitizeze". Ambele funcții și-au făcut treaba. Problema e că nu au aceeași părere despre ce înseamnă o etichetă. Oriunde ai două componente care parsează același input cu reguli ușor diferite, ai potențial pentru exact acest tip de bug.

De la XSS la execuție de PHP

Pagina de login încarcă user-profile.js, scriptul folosit pentru resetarea parolei. Pe pagina de login lipsesc însă câmpurile de profil pe care scriptul se așteaptă să le găsească, așa că mai multe verificări se compară cu undefined — și trec.

Aici intervine tehnica de DOM clobbering: variabila ajaxurl, nedefinită în acest context, poate fi suprascrisă cu elementele DOM injectate. Scriptul WordPress e astfel direcționat către o cerere REST aleasă de atacator, pe același domeniu.

Escaladarea finală folosește Same Origin Method Execution, o tehnică din 2022 a cercetătorului Paulos Yibelo. Cererea se execută cu cookie-urile de sesiune și nonce-urile reale ale administratorului. Cercetătorii au demonstrat mai multe căi, între care instalarea de plugin-uri și încărcarea de arhive ZIP arbitrare.

Dacă se ajunge la execuție de PHP, consecințele sunt cele obișnuite și complete: credențialele bazei de date, crearea unui administrator persistent, modificarea conținutului și comenzi la nivel de sistem de operare cu privilegiile procesului PHP.

• ▸The Hacker News — analiza tehnică a lanțului

Ce cere exploatarea, de fapt

Merită separate cele două jumătăți, pentru că au praguri foarte diferite.

XSS-ul de pe pagina de login nu cere nicio autentificare. A fost demonstrat pe profiluri Chrome noi, fără cookie-uri și fără credențiale WordPress. Acesta e partea ieftină.

Lanțul până la RCE cere în schimb ca victima să fie logată ca administrator și să interacționeze explicit cu o pagină controlată de atacator — în varianta demonstrată, un singur click obișnuit. Nu cere însă configurații neobișnuite de găzduire: funcționează pe instalări implicite.

Deci nu e „internetul ia foc", dar nici nu e teoretic. E exact profilul unui atac țintit împotriva unui administrator, iar un click pe un link e o barieră pe care istoria a demonstrat-o de multe ori ca fiind joasă.

Cine l-a găsit: un sistem autonom, în patru zile

Vulnerabilitatea a fost descoperită și raportată responsabil de pwn.ai. Sistemul lor autonom a pornit de la cercetarea SOME din 2022 ca punct de plecare și a reprodus lanțul în aproximativ patru zile, folosind modele open-source și un flux cu mai mulți agenți.

Asta e partea care schimbă calculul, nu bug-ul în sine. WordPress rulează pe o proporție uriașă din web, iar wp-login.php e una dintre cele mai citite bucăți de cod PHP din lume. Că a rămas acolo un XSS pre-auth până când l-a găsit un sistem automat spune ceva despre ce scapă revizuirii umane.

Consecința practică pentru apărare: dacă descoperirea de vulnerabilități în cod matur devine mai ieftină, ritmul apariției CVE-urilor în componentele pe care le folosești crește. Fereastra dintre publicare și exploatare nu se lărgește ca să compenseze.

Ce faci practic

• ▸Actualizează la 7.0.3 acum; dacă ai actualizări automate, confirmă că au rulat efectiv
• ▸Nu te baza pe măsurile de hardening ca înlocuitor — proiectul spune explicit că nu acoperă complet XSS-ul de la bază
• ▸Inventariază unde ai WordPress: instanțele uitate, de marketing sau de campanie, sunt cele care rămân nepatchuite
• ▸Tratează conturile de administrator ca active cu risc ridicat: sesiuni scurte, fără navigare generală din contul cu drepturi depline
• ▸Verifică jurnalele pentru încercări de login cu nume de utilizator care conțin paranteze unghiulare
• ▸Dacă rulezi o versiune mai veche de 4.7, ești în afara retroportării — migrarea nu mai e o discuție de planificat pe trimestrul viitor

• ▸NVD — CVE-2026-64638

Ce nu e confirmat

La momentul scrierii, avizul proiectului nu raportează exploatare în sălbăticie. Nu există un PoC public complet: detaliile tehnice au fost împărtășite presei de specialitate, iar testarea pe instalări curate s-a oprit la stadiul de XSS, lanțul complet până la execuția de PHP fiind demonstrat separat, pe o instalare locală.

Absența exploatării observate nu e o garanție și nu e un motiv de amânare. Pentru o vulnerabilitate cu patch disponibil într-un produs atât de răspândit, distanța dintre „nu se exploatează încă" și „se exploatează în masă" a fost istoric de zile.