Era o zi de vineri, spre after-amiază — genul de moment în care speri că nimic nu se mai întâmplă până luni. Telefonul a sunat. Un client, îngrijorat, mi-a citit un mesaj primit chiar atunci: „Traficul organic a scăzut cu 90% în ultimele trei zile.” Fără nicio schimbare recentă pe site, fără nicio campanie oprită, fără niciun motiv aparent.
Am deschis Google Search Console pentru domeniul respectiv. Primul lucru pe care l-am văzut a fost un avertisment de securitate: „Acest site poate fi compromis.” Al doilea lucru, și mai ciudat, a fost lista de pagini indexate recent — zeci de URL-uri pe care nu le crease nimeni din echipa clientului, cu titluri în caractere chinezești, promovând produse contrafăcute de la branduri cunoscute.
Prima ipoteză, și de ce era greșită
Reflexul inițial a fost să caut fișiere suspecte în directorul WordPress — plugin-uri necunoscute, teme modificate, fișiere PHP cu nume ciudate. Nimic. Fișierele arătau curate. Baza de date, la fel. Niciun cont de administrator nou, niciun plugin instalat recent, niciun semn evident de compromis din interior.
Ceea ce m-a făcut să mă opresc și să mă gândesc altfel a fost un detaliu simplu: dacă accesam site-ul direct din browser, arăta perfect normal. Dar dacă îl accesam printr-un simulator de Googlebot, vedeam cu totul altceva — o pagină plină de linkuri spre magazine chinezești, cu conținut generat automat. Site-ul avea două fețe, în funcție de cine îl vizita.
Descoperirea: cloaking, ascuns în locul cel mai puțin evident
Asta se numește cloaking — o tehnică prin care site-ul afișează conținut diferit vizitatorilor umani față de ce afișează motoarelor de căutare. Am verificat fișierul `.htaccess`, locul clasic unde se ascund astfel de reguli, și acolo era: o condiție care verifica user-agent-ul vizitatorului și, dacă recunoștea Googlebot, redirecționa cererea către un script PHP separat, ascuns adânc într-un folder de upload-uri, care genera pagina falsă din mers.
Dar cum ajunsese acolo? Fișierele curate din WordPress nu explicau nimic. Răspunsul a venit după ce am verificat jurnalele serverului din ultimele două săptămâni: o cerere neobișnuită către un formular vechi, dintr-un plugin abandonat de ani de zile, pe care nimeni nu-l mai folosea activ dar rămăsese instalat. Payload-ul din acea cerere exploata o vulnerabilitate de deserializare PHP — genul de atac care nu instalează un fișier evident, ci reconstruiește cod malițios direct în memorie, din date aparent inofensive, folosind clase PHP deja existente pe server.
Practic, atacatorii nu au adăugat cod nou vizibil. Au folosit codul deja existent pe server, într-un mod pe care dezvoltatorii lui originali nu l-au intenționat niciodată, ca să scrie fișierul `.htaccess` malițios. De-asta scanările standard de malware, care caută semnături de fișiere cunoscute, nu au găsit nimic — nu exista niciun fișier „rău” nou, doar o reconfigurare inteligentă a unor piese deja acolo.
Remedierea, și partea mai puțin tehnică a poveștii
Odată identificată cauza, curățarea propriu-zisă a fost partea ușoară: eliminarea regulilor din `.htaccess`, ștergerea scriptului ascuns, dezinstalarea completă a pluginului abandonat care servise drept poartă de intrare, și o scanare completă pentru a confirma că nu mai existau alte urme.
Partea mai grea a fost recuperarea din perspectiva Google. Un avertisment de securitate în Search Console nu dispare automat — trebuie solicitată explicit o reevaluare, după ce demonstrezi că problema a fost rezolvată. Asta a mai durat câteva zile, timp în care traficul organic a rămas afectat, chiar și după ce site-ul era deja curat.
Ce a rămas din întâmplarea asta
Lecția tehnică e simplă de rezumat: un plugin abandonat, care nu mai primește actualizări, e o ușă lăsată descuiată chiar dacă nu pare să facă nimic vizibil rău. Nimeni din echipa clientului nu-l mai folosea, nimeni nu se gândise să-l dezactiveze — exista pur și simplu, ca zeci de alte plugin-uri instalate de-a lungul anilor „pentru orice eventualitate”.
Lecția mai puțin tehnică e despre cât de înșelătoare poate fi liniștea aparentă a unui site. Nimic nu părea stricat. Fișierele arătau curate. Site-ul funcționa normal pentru oricine îl vizita direct. Singurul semn real al problemei era invizibil pentru proprietarul afacerii — vizibil doar pentru motorul de căutare, și doar pentru câteva zile, până când efectul asupra traficului a devenit imposibil de ignorat.
De atunci, verificarea periodică a plugin-urilor abandonate a devenit un pas standard, nu opțional, în orice audit pe care îl facem — indiferent cât de „inofensiv” pare un plugin vechi care doar stă acolo, neactualizat, dar aparent inactiv.
Dacă povestea asta ți se pare cunoscută
Dacă administrezi un site WordPress de câțiva ani, probabil ai și tu, undeva, un plugin instalat cu mult timp în urmă, pentru o funcționalitate de care nu mai ții minte exact de ce aveai nevoie. Nu strică nimic vizibil. Dar nici nu-l mai verifică nimeni.
Verificarea periodică a plugin-urilor active — și eliminarea celor abandonate — face parte din pachetele noastre de administrare WordPress, exact pentru genul ăsta de risc invizibil. De la 49 €/lună.
Curios dacă site-ul tău are vreun „pasager tăcut” de genul ăsta? Cere auditul gratuit — verificăm, fără obligații.