XSS2Shell: cum devine un mesaj de eroare la login o cale către execuție de cod pe server

Pe 7 august 2026 a fost făcută publică CVE-2026-64638, denumită XSS2Shell de cercetătorii care au descoperit-o. Este o vulnerabilitate de tip cross-site scripting care se declanșează fără autentificare, direct în ecranul de login al WordPress, și care în anumite condiții poate fi înlănțuită până la execuție de cod PHP pe server. Scorul atribuit este 8.9.

Nu o confunda cu wp2shell — sunt lucruri diferite

În aceeași perioadă circulă și wp2shell (CVE-2026-63030 și CVE-2026-60137), care vizează API-ul REST Batch, permite execuție de cod fără autentificare și preluarea completă a site-ului, și care este exploatată activ, chiar acum. Numele se aseamănă suficient încât confuzia este garantată, iar consecința practică a confuziei este gravă: cine crede că a rezolvat wp2shell pentru că a citit despre XSS2Shell rămâne expus la cea care se exploatează chiar acum.

Diferența, pe scurt: wp2shell trece prin API-ul REST și nu are nevoie de nimeni; XSS2Shell trece prin ecranul de login și, pentru a ajunge la execuție de cod, are nevoie ca un administrator autentificat să facă un clic. Ambele cer actualizare, dar prima este urgență, a doua este prioritate mare.

Mecanismul: două funcții care nu sunt de acord ce este un tag

Partea frumoasă tehnic — și cea mai instructivă — este cauza. WordPress folosește două mecanisme de curățare a conținutului, iar ele interpretează diferit același text. Funcția `strip_tags()` tratează un caracter „mai mic decât" urmat de spațiu într-un fel, iar parserul KSES în alt fel. Un nume de utilizator construit special, trimis într-o încercare eșuată de autentificare, este curățat de prima funcție într-un mod care lasă în urmă un șir pe care a doua funcție îl interpretează, mai târziu, drept HTML legitim.

Aceasta este o clasă de defect cunoscută sub numele de „parser differential": niciuna dintre cele două componente nu este greșită în sine, dar dezacordul dintre ele creează vulnerabilitatea. Este același tipar care produce probleme de contrabandă a cererilor HTTP sau de ocolire a filtrelor de fișiere. Lecția generală, valabilă în orice bază de cod: dacă aceeași dată trece prin două straturi de validare care nu împart aceeași definiție, diferența dintre ele este suprafață de atac.

De la XSS la cod pe server

• Codul injectat preia JavaScriptul propriu al WordPress, încărcat oricum pe pagina de login pentru fluxurile de resetare a parolei, și îl determină să execute cod în originea site-ului. Tehnica se numește Same Origin Method Execution — atacatorul nu aduce cod din exterior, ci deturnează codul legitim deja prezent.
• Odată ce rulează în originea site-ului, poate exfiltra Application Passwords ale unui administrator autentificat.
• Cu acele credențiale se poate încărca și activa un plugin, iar de acolo se ajunge la execuție de PHP cu drepturile utilizatorului sub care rulează serverul web.

Lanțul complet nu este automat. Cere ca un administrator de site individual să fie autentificat și să facă acțiunea, plus câteva condiții de configurare: Application Passwords active — ceea ce este cazul implicit — și un anumit script de profil încărcat pe acțiunea de login. Faptul că sunt necesare condiții nu este un motiv de relaxare, ci explicația pentru care scorul este 8.9 și nu 10.

Cine este afectat, exact

Aici există o nuanță pe care merită să o citești atent, pentru că relatările o simplifică. Codul care stă la baza problemei există de mult în WordPress, iar corecțiile au fost portate pe ramuri până la 4.7 — de unde și afirmațiile că „afectează tot". Însă calea efectiv exploatabilă a apărut în versiunea 6.4, odată cu introducerea unui flux nou de afișare a notificărilor de eroare la login. Versiunile 6.3 și anterioare nu sunt exploatabile pe acest drum, pentru că șirul supraviețuitor nu ajunge niciodată la a doua funcție de curățare.

Practic: intervalul vulnerabil este 6.4–7.0.2, iar versiunea reparată este 7.0.3. Dacă rulezi ceva mai vechi de 6.4, nu ești expus la acest defect anume — dar aproape sigur ești expus la altele, pentru că o instalare rămasă pe o versiune de acum trei ani nu a rămas acolo dintr-o decizie de securitate.

Ce faci, în ordine

• Actualizează la 7.0.3. Verifică apoi versiunea efectiv rulată, nu doar că actualizarea a fost declanșată.
• Verifică separat dacă ești expus la wp2shell, care se exploatează activ. Sunt două probleme distincte, cu două verificări distincte.
• Dezactivează Application Passwords dacă nu le folosești. Sunt active implicit și reprezintă veriga prin care XSS-ul devine acces persistent.
• Restricționează încărcarea de pluginuri din interfața de administrare pe site-urile de producție. Constanta `DISALLOW_FILE_MODS` rupe lanțul exact înainte de ultimul pas.
• Limitează numărul de conturi cu rol de administrator. Lanțul are nevoie de un administrator autentificat; cu cât sunt mai puțini și cu cât stau mai puțin autentificați, cu atât fereastra e mai îngustă.

De ce contează pentru cine nu are WordPress

Pentru că lanțul este un exemplu didactic aproape perfect de escaladare prin componente care, fiecare în parte, par inofensive. Un mesaj de eroare la login. O funcție de sanitizare. Un script de resetare a parolei. O funcționalitate de parole pentru aplicații. Un formular de încărcare de pluginuri. Niciuna nu este o vulnerabilitate; înlănțuite, duc la cod executat pe server.

Aceasta este și rațiunea pentru care „am scanat și nu am găsit nimic critic" spune mai puțin decât pare. Scanerele găsesc bine defecte individuale. Lanțurile de acest tip apar din interacțiuni, iar interacțiunile se descoperă prin testare cu context — cineva care înțelege ce înseamnă fiecare piesă în arhitectura respectivă.