Pe 17 septembrie 2026, echipa WordPress a lansat versiunea 7.1.1, o versiune de mentenanță aparent obișnuită. Printre cele 11 corecții de securitate incluse se afla însă una neobișnuită: o vulnerabilitate botezată "Click2Shell", care putea instala automat o temă pe site-ul unui administrator, fără ca acesta să apese vreun buton, doar din simplul fapt că deschidea un link.
Genul acesta de veste ridică rapid o întrebare pe care mulți proprietari de site-uri o tastează direct într-un motor de căutare sau într-un asistent AI: "cum știu dacă site-ul meu WordPress e vulnerabil" sau "ce fac dacă am ratat o actualizare importantă". Răspunsul scurt e că, în majoritatea cazurilor, un site actualizat la timp nu ajunge niciodată să fie afectat de acest tip de breșă.
Materialul de față explică, pe înțelesul oricui administrează un site, ce s-a întâmplat exact cu Click2Shell, de ce vulnerabilități de acest fel apar constant în ecosistemul WordPress și ce anume separă un site expus de unul protejat.
Ce este Click2Shell și cum a transformat un simplu link într-un atac
Numele vine din mecanismul atacului: un singur click, pe un link aparent nevinovat, putea deschide o breșă ("shell") către controlul site-ului. Cercetătorii de securitate de la pwn.ai, care au descoperit și raportat problema, au explicat că vulnerabilitatea exploata o neconcordanță tehnică între felul în care două componente WordPress interpretau același text dintr-un link.
Catalogul oficial de teme de pe WordPress.org citea textul din link ca pe un nume obișnuit de temă și returna o temă reală. Browserul administratorului, în schimb, refolosea exact același text, cu tot cu semnele de punctuație, într-un cod menit să identifice un element de pe pagină. Câteva caractere adăugate deliberat în link direcționau acel cod exact spre butonul de instalare, iar scriptul WordPress îl "apăsa" singur.
Pentru ca atacul să funcționeze, victima trebuia doar să fie deja autentificată în panoul de administrare și să deschidă linkul respectiv, de exemplu dintr-un email sau un mesaj aparent obișnuit. Sesiunea ei activă oferea automat permisiunile și tokenul de securitate necesare instalării, fără ca atacatorul să aibă nevoie de vreo parolă.
Instalarea unei teme oficiale, luată izolat, nu produce pagube. Problema reală apărea prin înlănțuirea a trei mecanisme tehnice distincte: injectarea prin selectorul de previzualizare a temei, încărcarea codului PHP al temei încă din etapa de previzualizare (înainte de activare) și, în final, un endpoint AJAX de instalare a pluginurilor care nu verifica suficient permisiunile utilizatorului. Combinate, cele trei permiteau rularea de cod PHP arbitrar direct pe server, în sesiunea administratorului păcălit.
De ce a fost posibil un asemenea atac pe cea mai folosită platformă de site-uri din lume
WordPress rămâne, la nivel global, cea mai răspândită platformă pentru site-uri web. Conform W3Techs, în septembrie 2026 WordPress rulează aproximativ 40,7% din toate site-urile de pe internet, respectiv aproape 6 din 10 site-uri construite pe un sistem de gestiune a conținutului cunoscut. Un asemenea nivel de adopție înseamnă și că orice vulnerabilitate din nucleul platformei are un impact potențial uriaș, motiv pentru care echipa de securitate WordPress tratează rapoartele de acest tip cu prioritate.
În cazul Click2Shell, procesul a funcționat exact așa cum ar trebui: vulnerabilitatea a fost raportată privat, echipa de securitate a validat-o și a pregătit corecția, iar patch-ul a ajuns public prin WordPress 7.1.1, fără ca detaliile tehnice complete să fie publicate înainte ca majoritatea site-urilor să aibă șansa să se actualizeze. Programul de divulgare a vulnerabilităților al WordPress, actualizat chiar în această perioadă, urmărește exact acest echilibru: timp suficient pentru corecție, înainte ca informația să devină publică.
Rămâne totuși un detaliu esențial, pe care mulți proprietari de site-uri îl ignoră: corecția există din 17 septembrie 2026, dar protejează doar site-urile care chiar au fost actualizate la această versiune. Un site rămas pe o versiune mai veche este, în continuare, expus, indiferent cât de recentă e corecția disponibilă.
Motorul WordPress e rareori punctul slab real
Un aspect care surprinde deseori pe cei care nu lucrează zilnic cu WordPress este că nucleul platformei nu reprezintă, de fapt, principala sursă de risc. Conform raportului Patchstack privind starea securității WordPress în 2026, din cele 11.334 de vulnerabilități noi descoperite în ecosistem, doar 6 au fost identificate în nucleul WordPress. Restul, adică marea majoritate, provin din pluginuri și teme instalate de utilizatori: 91% din vulnerabilități au fost găsite în pluginuri, iar 9% în teme.
Diferența se vede clar și în practică. Nucleul WordPress are o echipă dedicată de securitate, un proces de divulgare structurat și cicluri de testare riguroase. Un plugin descărcat de pe un site terț, actualizat rar sau abandonat de dezvoltator, nu beneficiază de aceleași garanții, chiar dacă rulează pe același site și are acces la aceleași date.
Un alt element care schimbă radical miza este viteza cu care vulnerabilitățile odată publicate ajung să fie exploatate efectiv, în practică, pe site-uri reale. Un plugin de completare formulare sau un modul de galerie foto, instalat cu ani în urmă și uitat complet, poate deveni exact punctul de intrare pentru un atac, chiar dacă restul site-ului este actualizat impecabil.
Sursa: Patchstack, State of WordPress Security in 2026.
Practic, fereastra de timp dintre apariția unei corecții și momentul în care un site neactualizat devine țintă reală se măsoară în ore, nu în săptămâni. Aceeași sursă arată că 46% dintre vulnerabilitățile descoperite în 2025 nu aveau încă un patch disponibil la momentul dezvăluirii publice, ceea ce face și mai importantă viteza de reacție a echipei care administrează site-ul, odată ce o corecție devine disponibilă.
Site actualizat la timp, față de site lăsat "așa cum e" - diferența reală
Diferența dintre un site întreținut corect și unul ignorat după lansare se vede rareori în aspectul vizual - ea apare în ce se întâmplă în spatele scenei, exact acolo unde apar și se exploatează vulnerabilitățile de tipul Click2Shell.
| Aspect | Site fără mentenanță activă | Site cu mentenanță activă |
|---|---|---|
| Nucleu WordPress | Rămâne pe versiunea instalată la lansare, uneori luni sau ani | Actualizat la scurt timp după fiecare versiune de securitate |
| Pluginuri și teme | Actualizate ocazional sau deloc, adesea fără să se știe câte sunt instalate | Inventariate, actualizate constant, cele nefolosite sunt eliminate |
| Conturi de administrator | Un singur cont, adesea partajat între mai multe persoane | Conturi separate, cu permisiuni limitate la ce e strict necesar |
| Reacție la o vulnerabilitate nouă | Depinde dacă și când proprietarul află despre ea | Aplicată în cadrul unui proces stabilit, imediat după testare |
| Backup-uri | Absente sau netestate, uneori descoperite abia după un incident | Automate, periodice și verificate că pot fi restaurate |
Un site construit corect din start, fie pe WordPress, fie pe o platformă personalizată, nu devine automat imun la vulnerabilități noi. Nicio platformă nu e complet ferită de acest risc, inclusiv nucleul WordPress, așa cum arată chiar cazul Click2Shell. Diferența reală o face procesul care urmează după lansare, nu alegerea inițială a platformei.
Pentru un site de afaceri, cu comenzi sau formulare de contact active, timpul contează dublu. O oră de indisponibilitate cauzată de un atac reușit înseamnă comenzi pierdute, dar și un semnal de neîncredere pentru vizitatorii care nimeresc peste un site compromis sau marcat ca nesigur de browser.
Ce poți verifica acum, concret, pe propriul site WordPress
Nu ai nevoie de cunoștințe tehnice avansate pentru un prim control rapid. Din panoul de administrare WordPress, secțiunea "Actualizări" arată direct dacă nucleul, pluginurile sau tema activă au versiuni mai noi disponibile.
- Verifică dacă versiunea de WordPress instalată este 7.1.1 sau mai recentă
- Actualizează toate pluginurile și temele care afișează o versiune nouă disponibilă
- Elimină pluginurile și temele instalate, dar neactive de mult timp - rămân o țintă chiar dacă nu sunt folosite
- Activează autentificarea în doi pași pentru toate conturile cu drept de administrator
- Confirmă că există un backup recent și testat, dinainte de a aplica actualizări majore
O întrebare firească în acest punct, mai ales pentru cineva fără experiență tehnică, este ce se întâmplă dacă o actualizare "strică" ceva pe site, un plugin care nu mai funcționează corect sau un aspect vizual care se modifică neașteptat. Din acest motiv, actualizările importante se testează întâi pe o copie a site-ului (un mediu de staging), nu direct pe site-ul live, iar existența unui backup recent face ca orice problemă neprevăzută să poată fi anulată rapid.
Greșeli frecvente în gestionarea actualizărilor unui site WordPress
Ignorarea notificărilor de actualizare luni la rând
Multe site-uri afișează în panoul de administrare notificări de actualizare de săptămâni sau luni, ignorate pur și simplu pentru că site-ul "funcționează, deci nu-i nimic în neregulă" - până în momentul în care chiar apare o problemă.
Folosirea de pluginuri sau teme piratate ("nulled")
Versiunile piratate ale unor pluginuri premium vin, adesea, cu cod malițios ascuns direct în ele sau nu mai primesc niciodată actualizări de securitate, indiferent cât de gravă e o vulnerabilitate descoperită ulterior.
Un singur cont de administrator, folosit de toată echipa
Când mai multe persoane folosesc aceleași date de autentificare, devine imposibil de stabilit cine a făcut o modificare și crește riscul ca acreditările să ajungă, din neatenție, într-un loc nesigur.
Lipsa unui proces clar pentru actualizări
Fără un flux stabilit - verificare periodică, testare pe staging, backup înainte de update - actualizările ajung să fie făcute la întâmplare, exact atunci când cineva își amintește sau, mai rău, abia după un incident.
De cele mai multe ori, cauza reală a acestor greșeli e lipsa de timp alocat constant acestui proces, mai degrabă decât lipsa de informație. Un site de afaceri are nevoie de cineva care urmărește activ actualizările de securitate după lansare, dincolo de echipa care l-a construit inițial și a trecut între timp la alt proiect.
De reținut
Click2Shell a devenit posibil prin combinarea a trei mecanisme tehnice minore, nu printr-o eroare grosieră de proiectare. Genul acesta de descoperiri apare constant, în orice platformă folosită de milioane de site-uri, iar corecțiile publicate rapid protejează doar site-urile care ajung, efectiv, să le și instaleze.
Cine caută astăzi dezvoltare WordPress pentru un site nou ar trebui să vadă în acest gen de vulnerabilitate un argument pentru a-l construi și întreține corect de la început, nu un motiv de a evita platforma. Riscul real vine din site-urile lansate și apoi lăsate fără nicio supraveghere după momentul livrării - alegerea platformei contează mult mai puțin. Un site nou, configurat corect din prima zi, cu un număr redus de pluginuri și un plan clar de actualizare, pornește oricum cu un avans real față de un site vechi, acumulat în timp din module adăugate ad-hoc de-a lungul anilor.
Întrebări frecvente
Site-ul meu WordPress a fost afectat de Click2Shell?
Doar dacă rulai o versiune WordPress mai veche de 7.1.1 la momentul atacului și un administrator autentificat a deschis un link special construit pentru a exploata vulnerabilitatea. Dacă site-ul este actualizat la 7.1.1 sau o versiune ulterioară, breșa este deja corectată și nu mai poate fi exploatată prin această metodă.
E suficient să actualizez doar nucleul WordPress pentru a fi în siguranță?
Nu în totalitate. Actualizarea nucleului corectează vulnerabilitatea Click2Shell, dar marea majoritate a breșelor de securitate din ecosistemul WordPress provin din pluginuri și teme, nu din nucleu. Un site sigur are nevoie de actualizări constante pe toate cele trei componente, nu doar pe platforma de bază.
Cât de repede trebuie aplicată o actualizare de securitate?
Cât mai curând posibil, ideal în primele 24 de ore de la publicare, testată în prealabil pe o copie a site-ului. Datele din industrie arată că aproape jumătate dintre vulnerabilitățile publicate sunt exploatate deja în prima zi, iar șapte din zece în prima săptămână.
Un site construit pe altă platformă decât WordPress e ferit de acest tip de risc?
Nu automat. Orice platformă web, indiferent de tehnologia din spate, poate avea vulnerabilități noi descoperite periodic. Diferența reală dintre un site expus și unul protejat ține de existența unui proces activ de actualizare, monitorizare și testare după lansare, mult mai mult decât de platforma aleasă.
Ai nevoie de un site web profesional?
Discută cu echipa Dev Factory despre proiectul tău.
Discută cu un dezvoltator