Sari la conținut
Braincap
← Toate articolele

XSS2Shell: un XSS pe login-ul WordPress ajunge la execuție de cod pe server

de Claudiu Hulea · IT Management Consultant

Ilustrație: un payload cu spațiu între paranteză și numele etichetei trece de primul filtru WordPress ca inofensiv, dar al doilea filtru îl parsează ca etichetă validă, ducând la XSS și execuție de cod

WordPress a reparat o vulnerabilitate critică în propriul nucleu, CVE-2026-64638, poreclită „XSS2Shell”, care pornește ca un cross-site scripting neautentificat pe ecranul de login și se poate înlănțui până la execuție de cod pe server. E în core, nu într-un plugin, atinge practic orice instalare neactualizată și, fiindcă WordPress rulează în jur de 43% din web, suprafața e uriașă. Dacă administrezi un site WordPress, actualizează la 7.0.3 acum.

Ce e, pe scurt

Totul începe pe wp-login.php. Când trimiți un nume de utilizator inexistent, WordPress îl afișează înapoi într-un mesaj de eroare. Aici, un atacator neautentificat poate strecura cod care se execută în browser, adică un XSS reflectat, fără să aibă vreun cont.

Saltul de la XSS la execuție de cod pe server cere ca un administrator să deschidă pagina pregătită de atacator. Printr-un lanț care abuzează sesiunea acelui administrator, atacatorul ajunge să încarce un plugin malițios, iar fișierele acelui plugin rulează cod PHP pe server. Nu redăm pașii, dar ideea e clară: de la un câmp de login la control complet.

Cauza: doi curățători care nu se înțeleg

Partea interesantă e cauza-rădăcină, fiindcă e o clasă de defect pe care o vezi peste tot. WordPress trece numele de utilizator prin mai multe straturi de sanitizare. Primul, wp_strip_all_tags, nu recunoaște o etichetă scrisă cu un spațiu între paranteza unghiulară și nume, de exemplu < area, așa că o lasă să treacă neatinsă. Al doilea strat, wp_kses_post, o parsează corect ca pe un <area> valid și o acceptă.

Cei doi nu văd același lucru. Un input pe care primul filtru îl consideră inofensiv devine, la al doilea, o etichetă HTML funcțională. Exact acest dezacord de parser deschide XSS-ul. E aceeași poveste ca la orice graniță unde o verificare trece, dar efectul real diferă de ce a crezut verificarea.

De ce e serios

Trei motive.

E în nucleul WordPress, nu într-un plugin obscur pe care l-ai putea dezinstala. Dacă rulezi WordPress neactualizat, ești expus.

E pre-auth la livrare. Atacatorul nu are nevoie de cont ca să trimită payload-ul, doar de un administrator care deschide linkul.

Are deja exploit public. Potrivit relatărilor, la o zi de la dezvăluire a apărut pe GitHub un instrument care parcurge tot lanțul. Scorul CVSS raportat e ridicat, în jur de 8,9. La dezvăluire nu erau dovezi confirmate de exploatare în sălbăticie, dar cu cod public fereastra e deja deschisă.

Cronologie

Potrivit celor care au descoperit-o, pwn.ai:

  • 26 iulie 2026, descoperire.
  • 6 august 2026, WordPress publică fix-ul în versiunea 7.0.3, backportat pe toate ramurile întreținute, până la 4.7.
  • 7 august 2026, dezvăluire publică.

Un detaliu care merită notat: vulnerabilitatea a fost găsită autonom de un sistem AI. E semnalul aceleiași direcții despre care tot scriem, cercetarea de securitate accelerată de mașini, în ambele tabere.

Ce ai de făcut

Apărarea are un pas obligatoriu și câțiva care reduc expunerea.

Actualizează la 7.0.3, acum. Site-urile cu update automat în fundal ar trebui să îl aibă deja, dar nu presupune. Verifică versiunea reală a instalării, mai ales pe site-urile self-hosted, unde actualizarea cere adesea intervenție manuală.

Revizuiește Application Passwords. Lanțul de atac fură o astfel de parolă de aplicație. Revocă-le pe cele neutilizate și tratează-le ca pe niște chei, nu ca pe o comoditate.

Redu expunerea ecranului de login. Limitează accesul la wp-login.php și wp-admin printr-o listă de IP-uri, un WAF în față sau autentificare suplimentară. Nu oprește singur acest lanț, dar micșorează cine poate livra payload-ul. Patch-ul rămâne reparația reală.

Monitorizează. Un plugin instalat pe neașteptate sau fișiere noi în wp-content/plugins sunt exact semnalul de urmărit după acest tip de atac.

Lecția

Dincolo de acest CVE, lecția e reutilizabilă. Un input pe care un filtru îl declară curat poate fi văzut altfel de următorul parser. Nu te baza pe faptul că ai chemat o funcție de sanitizare, verifică ce ajunge de fapt în HTML, în contextul în care ajunge.

Apărarea corectă e escape la ieșire, în contextul potrivit: HTML, atribut sau URL. Exact asta a făcut și WordPress în fix, adăugând esc_html, esc_url și esc_attr la punctul de afișare. Sanitizarea la intrare ajută, dar encoding-ul corect la output e cel care închide gaura. E aceeași disciplină ca „verifică efectul, nu configurarea”, mutată în stratul web.

Vrei să știi ce versiuni și ce plugin-uri rulează de fapt pe site-urile tale, și cine poate ajunge la ecranul de login? Scrie-ne și pornim de la un audit.

Surse

Întrebări frecvente

Ce este XSS2Shell (CVE-2026-64638)?

O vulnerabilitate în nucleul WordPress care pornește ca un cross-site scripting neautentificat pe ecranul de login (wp-login.php) și se poate înlănțui până la execuție de cod PHP pe server. Afectează practic orice instalare neactualizată dinainte de versiunea 7.0.3. Fiindcă WordPress rulează în jur de 43% din web, suprafața e uriașă.

Care e cauza-rădăcină?

Un dezacord de parser între două straturi de sanitizare. Primul, wp_strip_all_tags, nu recunoaște o etichetă scrisă cu un spațiu între paranteza unghiulară și nume (de exemplu „< area”), așa că o lasă să treacă. Al doilea strat, wp_kses_post, o parsează corect ca pe un „<area>” valid și o acceptă. Cei doi nu văd același lucru, iar acel dezacord deschide XSS-ul.

Are nevoie atacatorul de un cont?

Nu pentru livrarea XSS-ului, care e neautentificat. Saltul de la XSS la execuție de cod pe server cere însă ca un administrator să deschidă pagina pregătită de atacator. Lanțul abuzează sesiunea acelui administrator, ajunge să încarce un plugin malițios, iar fișierele plugin-ului rulează cod PHP.

Ce trebuie să fac?

Actualizează la WordPress 7.0.3 acum; fix-ul e backportat pe toate ramurile întreținute, până la 4.7. Verifică versiunea reală a instalării, mai ales pe site-urile self-hosted. Revizuiește și revocă Application Passwords neutilizate (lanțul fură o astfel de parolă), limitează accesul la wp-login.php și wp-admin și monitorizează instalările neașteptate de plugin-uri.

Articole similare