WordPress wp2shell: RCE pre-auth, actualizează la 7.0.2

Pe 17 iulie, WordPress a lansat versiunea 7.0.2, iar aceasta nu a fost o actualizare de punct obișnuită. Închide un lanț pe care cercetătorii l-au numit wp2shell: două erori care, combinate, permit unui atacator anonim să execute cod pe o instalare implicită WordPress. Fără autentificare. Fără plugin vulnerabil. Fără temă ciudată. Un singur request POST modificat către REST API, iar serverul poate ajunge să aibă un cont de administrator nou și un shell care răspunde la comenzi.

Lanțul constă în două CVE-uri. CVE-2026-63030 este o confuzie route/handler în endpoint-ul batch al REST API, evaluat ca critic, introdus în versiunea 6.9. CVE-2026-60137 este o injecție SQL în gestionarea author__not_in de către WP_Query, evaluat ca ridicat, care se întoarce până la versiunea 6.8. Separat, fiecare reprezintă o problemă. Înlănțuite, confuzia endpoint-ului batch dezleagă validarea de execuție și alimentează date nevalidate direct în injecția SQL, rezultând execuție de cod de la distanță fără autentificare. WordPress a activat actualizările automate forțate pentru site-urile afectate, ceea ce arată cum a evaluat echipa core riscul. Patchstack spune că vede deja tentative de exploatare în jurnalele sale.

Iată harta versiunilor. Lanțul complet RCE afectează versiunile de la 6.9.0 la 7.0.1. Ramura 6.8 conține doar injecția SQL, nu confuzia de rută care o face accesibilă fără autentificare. Corecțiile au apărut în 6.8.6, 6.9.5 și 7.0.2, plus un beta2 pentru 7.1 pentru cei care testează ramura următoare. Confuzia de rută a fost raportată de Adam Kues de la Assetnote, brațul de cercetare al Searchlight Cyber, prin programul HackerOne al WordPress. Injecția SQL a fost raportată separat de TF1T, dtro și haongo.

De ce aceasta este mai gravă decât CVE-ul obișnuit WordPress

Cele mai multe vulnerabilități WordPress se află în plugin-uri. Le poți audita, fixa sau elimina. Aceasta se află în core, pe o instalare implicită, accesibilă înainte de autentificare. Această combinație este rară și este exact profilul pe care atacatorii îl automatizează primii. Un bug de core pre-auth pe platforma care rulează o mare parte din web este un eveniment de scanare în masă, nu unul țintit. Script-urile de proof-of-concept publice au apărut la o zi sau două de la divulgare, iar actualizările forțate ajung doar la site-urile care au auto-actualizarea activată și care se conectează efectiv. Multe nu o fac.

Există un detaliu operațional demn de menționat. Raportările despre bug notează că traseul RCE este cel mai ușor de parcurs când un site nu rulează un cache de obiecte persistent, ceea ce reprezintă configurația implicită pentru o mulțime de instalări mici și medii. Deci site-urile cel mai puțin susceptibile să aibă o configurare consolidată sunt cele mai expuse. Asta se potrivește cu ceea ce vedem în angajamentele de pentesting pentru studiouri de gaming: riscul real se află de obicei în configurarea implicită plictisitoare, nu în cazul extrem exotic la care toată lumea petrece timp îngrijorându-se.

Ce să faci în această săptămână

În primul rând, aplică patch-ul. Dacă rulezi WordPress 6.8 până la 7.0.1 oriunde, treci la 7.0.2 sau la backport-ul corespunzător 6.9.5 sau 6.8.6 acum, nu la fereastra de întreținere următoare. Apoi confirmă că actualizarea a fost aplicată efectiv. Actualizările automate forțate pot eșua în tăcere în spatele unui reverse proxy sau pe un sistem de fișiere blocat, deci verifică versiunea raportată în loc să ai încredere că mecanismul și-a făcut treaba.

În al doilea rând, presupune că intervalul dintre lansarea versiunii 6.9 și 17 iulie a fost o fereastră deschisă și caută semne că cineva a trecut prin ea. Verifică dacă există utilizatori admin pe care nu îi recunoști, fișiere neașteptate sub wp-content/plugins/ și conexiuni de ieșire de la gazda web pe care nu le poți explica. Un patch curat nu anulează un compromis care a avut loc deja, iar acest bug lasă un atacator cu exact tipul de acces persistent care supraviețuiește unei actualizări.

În al treilea rând, pune un control în fața aplicației, nu doar înăuntrul ei. Cloudflare a livrat o regulă WAF de urgență în ziua divulgării. Când configurăm Cloudflare pentru clienți care au nevoie de protecție DDoS și un WAF, o regulă gestionată pentru un CVE de core proaspăt ca acesta câștigă ore sau zile de acoperire în timp ce un patch se răspândește pe o flotă de site-uri. Din munca noastră pe platforme de travel, această fereastră de patch virtual este adesea diferența dintre reacția în minute și reacția după fapt.

Pentru echipele care construiesc pe PHP mai larg, lecția reală este despre limitele de încredere. Acest lanț a funcționat deoarece un strat de validare și un strat de execuție nu au căzut de acord cu privire la ce conținea request-ul. Vedem aceeași clasă de bug în aplicațiile personalizate tot timpul: inputul este verificat într-un loc și consumat în altul, iar cele două se îndepărtează până când un atacator strecoară ceva între ele. În munca noastră cu PHP și Docker, obiceiul care îl prinde este tratarea fiecărui request ca ostil până când stratul exact care rulează interogarea l-a revalidat. Validarea care se întâmplă la trei funcții distanță de baza de date nu este o validare pe care te poți baza.

Rulăm acest tip de revizuire pre-auth pentru clienți enterprise cu mize reale de conformitate, iar experiența echipei constă în găsirea request-ului care nu ar trebui să funcționeze, dar o face. Dacă „am aplicat patch-ul, dar nu suntem siguri că nimic nu a intrat înainte” sună familiar, să discutăm.