Cinci intrări prin nucleul WordPress: un site redirecționat șase săptămâni spre jocuri de noroc

Sesizarea a venit de la client: cine deschidea site-ul firmei ajungea pe un site străin de jocuri de noroc. Nu o pagină anume, nu doar de pe telefon — orice adresă a site-ului, în oricare dintre cele patru limbi în care era publicat.

Redirecționarea era doar partea vizibilă. În spatele ei, site-ul fusese preluat cu mai bine de două luni înainte, pe 21 iulie 2026, printr-o vulnerabilitate din nucleul WordPress, nu dintr-un modul sau dintr-o temă. Iar atacatorul nu a intrat o dată, ci de cinci ori, lăsând de fiecare dată câte un cont de administrator nou.

Cum a intrat: o vulnerabilitate în nucleul WordPress

Site-ul rula WordPress 6.9.4. Versiunile 6.9.0 – 6.9.4 (și 7.0.0 – 7.0.1) sunt afectate de wp2shell — două vulnerabilități înlănțuite, CVE-2026-63030 și CVE-2026-60137, prin care oricine poate rula cod pe server fără să fie autentificat. Nu e nevoie de o parolă ghicită, de un modul vechi sau de o greșeală a administratorului: e suficient ca nucleul să fie pe una dintre versiunile afectate.

Asta schimbă o idee comună despre securitatea WordPress. „Am doar module de încredere și le țin la zi” nu protejează un site al cărui nucleu nu se actualizează. Aici, actualizările automate ale nucleului nu ajunseseră la versiunea corectată, iar nimeni nu a observat.

Fiecare exploatare a lăsat în baza de date aceeași amprentă, ceea ce ne-a permis să le numărăm cu precizie: un post de tip customize_changeset datat artificial 1 ianuarie 2020, un post de tip request cu un status inexistent în WordPress, o intrare de cache oEmbed și elemente de meniu către adrese de test. Cinci amprente, cinci conturi de administrator, cinci intrări distincte.

Ce a făcut atacatorul cu accesul

• Cinci conturi de administrator, create între 21 iulie și 17 august, cu nume generate automat și adrese de email pe domenii inexistente. Unul avea încă o sesiune activă la momentul intervenției.
• Un manager de fișiere instalat ca plugin. Pe 17 august, atacatorul a instalat și activat WP File Manager — un plugin legitim, dar care oferă din panoul de administrare acces complet la fișierele de pe server. Nu exista pe site înainte.
• Circa 50 de pagini statice de spam („KERA4D Main Game Online x …”), puse în directoare cu aceleași nume ca paginile reale ale site-ului, în toate cele patru limbi. Serverul servește un fișier static înaintea WordPress-ului, așa că paginile false înlocuiau paginile reale la aceleași adrese. Fiecare director avea și propria hartă de site, ca să fie găsit rapid de motoarele de căutare.
• Fișiere noi pentru motoarele de căutare: hărți de site, fluxuri RSS, un robots.txt și un llms.txt — toate scrise de atacator, toate indicând paginile false.
• Un fișier de verificare Google Search Console. Cel mai probabil pentru a adăuga site-ul în contul atacatorului: de acolo poate cere indexarea paginilor false și poate vedea cum performează în căutări.
• Redirecționarea întregului site, pe 18 august, printr-o modificare în .htaccess: orice cerere primea un răspuns 302 către un domeniu străin. Din acel moment până la intervenție, timp de șase săptămâni, niciun vizitator nu a mai văzut site-ul real.

Ce nu am găsit — și de ce contează

Nu am găsit backdoor-uri PHP persistente. Căutarea de cod ofuscat și de webshell-uri pe tot site-ul, verificarea directorului de fișiere încărcate, a cheilor SSH și a sarcinilor programate nu au scos nimic.

Explicația e simplă și deloc liniștitoare: atacatorul nu avea nevoie de ele. Cu o vulnerabilitate care îi permitea să ruleze cod oricând, fără autentificare, un backdoor clasic ar fi fost redundant. Pe un astfel de site, lipsa fișierelor malițioase nu înseamnă că nu a existat control — înseamnă că ușa principală a rămas deschisă. De aceea actualizarea nucleului a fost parte din curățare, nu o recomandare pentru mai târziu.

Cronologia

9 aprilie 2026

Ultima copie de siguranță curată a site-ului. A servit ca punct de comparație pentru tot restul investigației.

21 iulie 2026, 02:03

Prima exploatare wp2shell. Primul cont de administrator al atacatorului.

6 – 17 august 2026

Încă patru exploatări, încă patru conturi de administrator. Unul dintre ele rămâne cu o sesiune activă.

17 august 2026, 17:40

Instalat și activat pluginul WP File Manager.

17 august 2026, 17:54 – 17:55

În două minute apar paginile de spam, hărțile de site, fluxurile RSS, robots.txt, llms.txt și fișierul de verificare Google.

18 august 2026, 06:12

.htaccess modificat: tot site-ul redirecționează către un domeniu de jocuri de noroc.

29 septembrie 2026, 11:15

Începe intervenția: arhivarea probelor, apoi eliminarea compromiterii.

29 septembrie 2026, 12:30

Site curat, actualizat și verificat, public și în panoul de administrare.

Curățarea, pas cu pas

• Arhivarea probelor înainte de orice modificare — baza de date completă și toate fișierele infectate, păstrate în afara zonei publice.
• Oprirea redirecționării. Regula atacatorului a fost scoasă din .htaccess, păstrând regulile legitime ale serverului și refăcând blocul standard WordPress.
• Ștergerea spamului static: 16 directoare cu 50 de pagini și 50 de hărți de site, plus fluxurile, hărțile principale, robots.txt, llms.txt și fișierul de verificare Google. Pentru fiecare fișier am confirmat că nu exista în copia de siguranță din aprilie — nu am șters nimic doar pentru că „arăta suspect”.
• Eliminarea conturilor. Cei cinci administratori ai atacatorului și conținutul lor, apoi închiderea tuturor sesiunilor active.
• Curățarea bazei de date: 22 de posturi lăsate de exploit, 45 de rânduri orfane cu elementele de meniu false și opțiunea de configurare a managerului de fișiere.
• Dezinstalarea WP File Manager, împreună cu directorul lui de date.
• Regenerarea cheilor de securitate WordPress, care invalidează orice cookie de autentificare existent — inclusiv sesiunea încă activă a atacatorului.
• Actualizarea nucleului de la 6.9.4 la 7.1.2, cu toate traducerile. Acesta e pasul care închide efectiv vulnerabilitatea.
• Reducerea suprafeței de atac: actualizarea tuturor modulelor active, ștergerea a 18 module inactive și a două teme nefolosite, plus eliminarea unui modul de popup-uri cu patru vulnerabilități cunoscute, care nu mai avea niciun popup configurat.

O regulă de securitate care exista doar pe hârtie

Directorul de fișiere încărcate avea deja o regulă care interzicea execuția PHP — pusă de soluția de securitate a serverului. Nu am considerat-o suficientă doar pentru că exista, și am testat-o: am plasat un fișier PHP inofensiv în director și l-am cerut din browser. S-a executat.

Regula era scrisă într-o sintaxă pe care serverul web folosit (LiteSpeed) nu o respecta în acel context. Am înlocuit-o cu o regulă de rescriere din .htaccess-ul principal, care răspunde cu 403 la orice fișier executabil din directorul de încărcări, și am retestat: refuzat.

Aceeași problemă a scos la iveală ceva mai grav. Două module de backup păstrau în wp-content arhive vechi ale site-ului — aproape 1,9 GB, inclusiv o copie a bazei de date din 2023 cu hash-urile parolelor. Erau „protejate” de același tip de regulă și, în practică, puteau fi descărcate de oricine cunoștea sau ghicea numele fișierului.

Lecția generală: o regulă de securitate se verifică printr-o cerere efectivă, nu prin prezența ei în fișier.

Verificările de la final

• nucleul WordPress, față de semnăturile oficiale — trece integral
• modulele din depozitul oficial WordPress, față de semnăturile oficiale — trec integral
• tema și modulele comerciale — identice cu copia de siguranță curată din aprilie
• căutare de webshell-uri și cod ofuscat pe tot site-ul — fără rezultate; niciun fișier PHP în directorul de încărcări
• chei SSH și sarcini programate — nimic străin
• paginile publice, în toate cele patru limbi — conținut real, fără spam, fără redirecționare
• formularele și galeriile — prezente pe toate paginile pe care existau înainte
• panoul de administrare — funcțional, fără erori fatale în jurnal
• administratori — doar cei doi legitimi, cu roluri nemodificate, fără parole de aplicație
• execuția PHP în directorul de încărcări — refuzată (403), verificată printr-o cerere efectivă
• listarea utilizatorilor prin API-ul REST — blocată

Ce i-am recomandat clientului

• Mutarea sau ștergerea arhivelor de backup din zona publică. Prioritate maximă: conțin baza de date cu hash-urile parolelor.
• Schimbarea parolei bazei de date. Atacatorul putea rula cod pe server, deci a putut citi fișierul de configurare.
• Schimbarea parolelor administratorilor — din același motiv, hash-urile lor au fost accesibile.
• Curățarea Google Search Console: eliminarea proprietarilor necunoscuți ai site-ului, apoi cererea de reindexare. Google indexase paginile false, iar ele rămân în rezultate până sunt recitite.
• Refacerea protecției anti-spam pe formulare, eliminată odată cu un modul șters de client în timpul intervenției.

Ce merită reținut

• Nucleul WordPress e și el o suprafață de atac. Aici nu a fost vina unui modul uitat sau a unei parole slabe: versiunea de WordPress era suficientă. Dacă site-ul tău rulează 6.9.0 – 6.9.4 sau 7.0.0 – 7.0.1, actualizează-l acum.
• Lipsa backdoor-urilor nu e o veste bună când vulnerabilitatea de intrare e încă deschisă. Curățarea fără actualizare ar fi durat până la următoarea exploatare.
• O copie de siguranță veche e un martor. Fiecare fișier șters a fost comparat mai întâi cu starea din aprilie. Fără ea, separarea fișierelor atacatorului de cele ale site-ului ar fi fost o estimare.
• Regulile de securitate se testează, nu se citesc. Două protecții „active” de pe acest site nu funcționau deloc.

Același tip de monetizare prin spam SEO, dar cu fișiere malițioase pe disc și alt vector de intrare, apare în cazul magazinului WooCommerce căzut cu pagină albă. Cum scoți un site din avertismentele Google după o astfel de compromitere e explicat în ghidul de deblocare, iar ce presupune o intervenție completă, pe pagina de curățare malware WordPress.

Anexă tehnică — indicatori de compromitere

Pentru administratorii WordPress și pentru colegii din industrie care vor să verifice dacă un site a fost exploatat prin wp2shell:

Vulnerabilitate

wp2shell — CVE-2026-63030 + CVE-2026-60137, execuție de cod fără autentificare în nucleul WordPress 6.9.0 – 6.9.4 și 7.0.0 – 7.0.1

Conturi de administrator

login wp2_*, w2s_* sau wpsvc_*; email pe @wp2shell.invalid, @wp2shell.local sau @wordpress-svc.internal

Urme în baza de date (la fiecare exploatare)

post customize_changeset cu post_date = 2020-01-01 00:00:00; post request cu post_status = 'parse'; o intrare oembed_cache

Elemente de meniu false

postmeta _menu_item_url către wp2shell[.]com sau example[.]invalid, cu post_id de ordinul miliardelor, fără post părinte

Plugin instalat de atacator

WP File Manager 8.0.4, cu opțiunea fm_key în baza de date și directorul wp-content/uploads/wp-file-manager-pro/

Spam static

directoare cu index.html și sitemap.xml proprii, cu aceleași nume ca paginile reale, titluri „KERA4D Main Game Online x …”; plus feed.xml, rss.xml, sitemap-home.xml, robots.txt, llms.txt și un fișier google*.html de verificare Search Console în rădăcina site-ului

Redirecționare

regulă 302 pentru tot site-ul în .htaccess, către tokesawit[.]online (adresă dezactivată aici ca să nu fie accesată din greșeală)

Verificare recomandată (conturi)

lista administratorilor, comparată cu cei pe care îi cunoști; orice cont nou cu email pe un domeniu inexistent este un semn clar

Verificare recomandată (fișiere statice)

fișiere .html sau .xml în rădăcina site-ului sau în directoare cu nume de pagini, care nu există într-o copie de siguranță mai veche

Verificare recomandată (reguli de protecție)

un fișier PHP inofensiv în wp-content/uploads/, cerut din browser: orice răspuns diferit de refuz înseamnă că regula nu funcționează

Mediu

WordPress 6.9.4 · site multilingv (4 limbi) · constructor de pagini comercial · găzduire LiteSpeed