XSS2Shell (CVE-2026-64638): o autentificare WordPress eșuată, două parsere care nu se înțeleg și o cale către execuție PHP

Pe 7 august 2026, cercetătorii au dezvăluit CVE-2026-64638, poreclit XSS2Shell: o vulnerabilitate de tip cross-site scripting pre-autentificare în nucleul WordPress, evaluată la CVSS 8,9, care în anumite condiții poate fi înlănțuită până la execuție de cod PHP pe server.

XSS-ul reflectat în sine nu are nevoie de nimic — niciun cont, nicio interacțiune dincolo de accesarea linkului otrăvit. Un singur POST către /wp-login.php care poartă un parametru „log" construit special livrează payload-ul prin mesajul de eroare al autentificării eșuate. Dată fiind răspândirea WordPress, populația expusă e uriașă; estimările o plasează la sute de milioane de site-uri.

Defectul e o neînțelegere între două parsere

Merită înțeles chiar dacă nu atingi niciodată WordPress, pentru că această clasă de eșec e peste tot. Numele de utilizator dintr-o autentificare eșuată trece printr-o sanitizare WordPress care se bazează pe funcția PHP strip_tags(). Aceasta tratează un „<" drept început de etichetă doar când e urmat de un caracter alfanumeric — așa că un payload scris ca „< area x=y>", cu spațiu după paranteză, îi supraviețuiește sub formă de text inofensiv.

Acel șir supraviețuitor ajunge apoi la wp_kses_post(), când e randată eroarea de autentificare — o cale de cod adăugată în WordPress 6.4. KSES folosește alt parser, iar acela citește „< area>" drept etichetă HTML autentică. Pentru că <area> se află pe lista albă, e lăsată să treacă și ajunge în pagină.

Nicio funcție nu e defectă luată separat. Vulnerabilitatea trăiește în spațiul dintre două componente care se comportă fiecare rezonabil și interpretează diferit același input. De fiecare dată când inputul traversează granița dintre două parsere — sanitizare către randare, proxy către aplicație, gateway către backend — acel spațiu merită auditat. Remedierea oficială reflectă asta: aplică esc_html() în punctul de interpolare din wp-includes/user.php, codificând valoarea înainte ca vreuna dintre sanitizări să aibă o opinie.

De la XSS la shell — și condițiile care îl limitează

Distincția contează la triaj și merită spusă clar: XSS-ul pre-autentificare afectează pe toată lumea din intervalul vulnerabil; preluarea serverului cere ca un administrator să fie autentificat și să interacționeze. Nu coborî urgența pe baza asta — o sesiune de admin e o stare obișnuită pe un site administrat activ — dar prioritizează în consecință dacă alegi între sute de instanțe.

• DOM-ul injectat deturnează JavaScript-ul de profil pe care WordPress îl încarcă deja în pagina de login pentru fluxul de resetare a parolei
• Escaladarea folosește Same Origin Method Execution (SOME), tehnică ce întoarce împotriva site-ului propriile lui scripturi
• Lanțul fură apoi un Application Password din profilul unui administrator autentificat, încarcă un plugin prin endpoint-uri REST deturnate și execută PHP cu utilizatorul serverului web
• RCE-ul complet cere un administrator de site autentificat în același browser, fluxul de resetare a parolei activat (implicit) și alte condiții de implementare — semnificativ mai restrânse decât XSS-ul în sine

Versiuni și cum verifici rapid

Vulnerabile: WordPress 6.4 până la 7.0.2. Versiunile 6.3 și anterioare nu sunt exploatabile pe această cale, pentru că randarea erorii de autentificare nu folosea încă wp_kses_post(). Remediat: WordPress 7.0.3, cu backport-uri pe ramurile suportate până la 4.7, ca măsură de precauție. Site-urile cu actualizări automate în fundal ar trebui să îl primească fără intervenție — dar „ar trebui" nu înseamnă „au primit", deci verifică.

# Un singur site, cu WP-CLI
wp core version
wp core update

# Fără WP-CLI — citește versiunea din sistemul de fișiere
grep -h '\$wp_version =' wp-includes/version.php

# Scanează un director de hosting cu multe site-uri
for d in /var/www/*/; do
  printf "%-40s " "$d"
  grep -h '\$wp_version =' "$d"wp-includes/version.php 2>/dev/null || echo 'fara wordpress'
done

Dacă nu poți patch-ui imediat

La momentul dezvăluirii nu există dovezi de exploatare în sălbăticie și niciun proof-of-concept public. E un motiv să te miști acum, nu unul să te relaxezi: fereastra dintre un aviz public și codul de exploit funcțional se micșorează constant, cum a demonstrat defectul TeamCity pe care l-am acoperit, ajuns în catalogul KEV al CISA la circa opt zile după livrarea patch-ului.

• La nivel de edge sau WAF, blochează cererile POST către /wp-login.php în care parametrul „log" conține %3C, adică „<" codificat URL. Potrivit cercetătorilor, nu restrânge regula la nume de etichete anume — KSES acceptă mai multe caractere de spațiu și mai multe etichete permise, deci o regulă bazată pe nume va fi ocolită
• Ca soluție temporară, dezactivează Application Passwords sau setează DISALLOW_FILE_MODS pentru a limita calea de escaladare. Ambele sunt mitigări, nu remedieri — îngustează lanțul fără să închidă XSS-ul
• Mută orice instanță aflată încă pe o ramură mai veche de 4.7 pe o ramură suportată. Nu e o sarcină de patch, e o migrare, și e restantă
• Adaugă logare a corpului cererilor pe căile de login și REST, ca să poți construi semnături de detecție și să răspunzi dacă a încercat cineva

Detaliul pe care nimeni n-ar trebui să-l sară: cine a găsit-o

Cercetătorii relatează că sistemul lor autonom a descoperit și reprodus lanțul de vulnerabilități după ce a fost îndreptat către cercetarea lui Paulos Yibelo din 2022 despre Same Origin Method Execution, drept punct de plecare. Munca a durat aproximativ patru zile, folosind modele open-source într-un flux multi-agent.

Citit alături de dezvăluirile pe care le-am acoperit săptămâna trecută — Anthropic, AI Security Institute din Marea Britanie, Meta — se conturează o imagine care nu e nici hype, nici panică. Acele incidente au arătat agenți comportându-se imprevizibil când izolarea a cedat. Acesta arată aceeași tehnologie făcând exact ce i s-a cerut, competent, împotriva unei baze de cod folosite de o parte semnificativă a internetului.

Implicația defensivă nu e că AI-ul va găsi orice bug. E că economia descoperirii se schimbă: defecte subtile de logică, pentru care înainte era nevoie de o săptămână din atenția unui specialist, pot fi acum scoase la suprafață de un flux care rulează în paralel pe multe ținte. Apărătorii ar trebui să presupună că intervalul dintre „acest bug există" și „cineva știe de el" se comprimă și să-și planifice cadența de patch pentru lumea aceea, nu pentru cea anterioară.

Awarely Monitor e construit pentru această cadență: urmărire continuă a NVD, CISA KEV, EUVD și GitHub Advisories, potrivită cu propriul tău inventar de active, cu prioritizare CVSS + EPSS, SLA tracking și audit trail imutabil — ca un CVE care afectează software pe care chiar îl rulezi să ajungă la tine ca alertă, nu ca titlu pe care se întâmplă să îl citești.