wp2shell, Node2Shell, PHP2Shell: vulnerabilitățile critice din 2026 se țin lanț – ce trebuie să faceți dacă ați fost afectați

Incidentele sunt tot mai dese

În 2026 am văzut, la distanță de câteva luni, trei vulnerabilități critice în componente de bază ale web-ului, toate cu execuție de cod la distanță și toate exploatate în practică la scurt timp după publicare: wp2shell (WordPress), Node2Shell/Broccoli2Shell (decodorul Brotli, cu efecte în Node.js, .NET și alte produse) și PHP2Shell (nucleul PHP). Detaliile tehnice și exploatările apar tot mai repede după avizele oficiale, deci fereastra dintre publicare și atac se scurtează.

Mesajul practic: nu mai este suficient să aplicați patch-uri „când avem timp”. Trebuie să știți ce rulați, să puteți actualiza rapid și să aveți un plan pentru ipoteza că ați fost deja vizați. Mai jos, cronologia verificată, apoi pașii.

Cronologia 2026, verificată pe surse

Datele provin din avize ale producătorilor, din catalogul CISA Known Exploited Vulnerabilities (KEV) și din presa de specialitate; sursele sunt listate la final. Unde sursele diferă (de exemplu data primelor atacuri), am notat explicit.

Cele trei vulnerabilități pe scurt

wp2shell afectează nucleul WordPress, nu un plugin: o instalare standard, fără pluginuri suplimentare, este vulnerabilă. Fiind în nucleu, remedierea este actualizarea WordPress la 6.8.6, 6.9.5 sau 7.0.2 (sau mai nouă).

Node2Shell/Broccoli2Shell este o scriere în afara limitelor în decodorul Brotli. O cerere sau un răspuns comprimat special poate provoca prăbușiri sau scurgeri de memorie și, în anumite condiții, execuție de cod. Fiind o bibliotecă, apare în multe produse: Node.js (ramurile 22, 24 și 26 au remedieri; ramurile 20, 23 și 25, ieșite din suport, nu), .NET, Bun, Envoy Proxy și clienți HTTP Python. Aplicațiile care își includ propriul Node.js sau propria copie Brotli au nevoie de remedierea furnizorului, nu doar de un upgrade al sistemului.

PHP2Shell înseamnă două vulnerabilități în nucleul PHP (gestionarea epuizării memoriei și starea internă rămasă între cereri). Potrivit PHP, sunt expuse toate instalările care servesc cereri web (PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP, LiteSpeed), mod_php fiind cel mai riscant. Actualizarea WordPress sau a pluginurilor nu remediază PHP2Shell: trebuie actualizat PHP-ul de pe server.

Sunteți afectați?

Răspunsul sigur se obține dintr-un inventar: ce versiuni de WordPress, PHP, Node.js, .NET și ce produse care le includ rulați, pe ce servere, la ce furnizor.

• WordPress: verificați versiunea. 6.9.0–6.9.4 și 7.0.0–7.0.1 sunt vulnerabile la lanțul complet; 6.8.x înainte de 6.8.6 este expus părții de injecție SQL.
• PHP: sunt vizate ramurile 8.5 (înainte de 8.5.12), 8.4 (înainte de 8.4.27), 8.3 (înainte de 8.3.36), 8.2 (înainte de 8.2.35) și cele ieșite din suport (8.1 și mai vechi). Pentru 7.4, 8.0 și 8.1 PHP a publicat doar backporturi minimale de cod sursă; unele distribuții livrează remedieri proprii. PHP 8.2 iese din suport pe 31.12.2026.
• Node.js, .NET și alte produse cu Brotli: verificați versiunea Node.js (22.23.4, 24.22.1, 26.12.1 sau mai nouă), aplicați actualizările Microsoft pentru .NET și avizele furnizorilor pentru produsele care includ Brotli. Atenție: pe distribuții cu backporturi, numărul versiunii bibliotecii poate rămâne vechi deși remedierea e aplicată; verificați changelog-ul pachetului.
• Hosting partajat sau gestionat: nu puteți actualiza direct. Cereți furnizorului confirmarea scrisă că platforma rulează versiuni remediate.
• Produse care includ aceste componente (panouri de administrare, echipamente de rețea, aplicații comerciale): CERT-EU atrage atenția că pot fi afectate chiar dacă nu administrați direct componenta. Verificați avizele furnizorilor.

Ce faceți acum, în ordine

1. Actualizați componentele afectate la versiunile remediate, apoi reporniți procesele și reconstruiți și redistribuiți imaginile de container care le includ. Actualizarea este singura soluție completă.

2. Dacă nu puteți actualiza imediat, aplicați măsurile temporare din avizele producătorilor: pentru PHP, de exemplu memory_limit=-1 prin php_admin_value, post_max_size redus și session.upload_progress.enabled=0 cu repornirea proceselor; pentru wp2shell, restricționarea accesului la endpoint-ul /wp-json/batch/v1 la nivel de WAF; pentru Brotli, blocarea cererilor comprimate Brotli la proxy sau dezactivarea decodării Brotli. Sunt punți, nu rezolvări; PHP precizează explicit că ele nu fac o instalare sigură.

3. Presupuneți că ați putut fi vizați între publicarea detaliilor și remedierea de la voi. Un patch oprește noile atacuri, dar nu elimină o compromitere deja produsă. Treceți la verificare înainte de a „curăța” orice.

Cum verificați dacă a existat o compromitere

Verificările de mai jos sunt defensive și orientative; absența semnelor nu garantează că sistemul este curat.

• Fișiere noi sau modificate în directorul rădăcină web, în directoarele de încărcări (uploads) și în directoarele de pluginuri/teme, în special fișiere .php apărute unde nu ar trebui să existe cod executabil – posibile web shell-uri. La WordPress, urmăriți și pluginuri necunoscute.
• Conturi de administrator noi (în CMS sau în baza de date), chei SSH sau sarcini programate (cron, timere systemd) pe care nu le recunoașteți.
• Procese și conexiuni de ieșire neobișnuite inițiate de utilizatorul serverului web sau al aplicației (adrese necunoscute, trafic periodic, descărcări de pe Internet).
• Jurnale web și de aplicație din jurul datelor de publicare încoace: cereri neobișnuit de mari sau multipart, cereri către /wp-json/batch/v1, erori repetate de memorie, erori fatale, reporniri ale proceselor.
• Modificări în fișierele de configurare, în baza de date sau în pagini publice.

Dacă găsiți semne: păstrați probele

Nu reinstalați, nu ștergeți și nu „curățați” sistemul înainte de a păstra probele. Păstrați jurnalele și copiile de siguranță, izolați de rețea (în loc să opriți) serverul suspect, notați ora și persoanele implicate. Fără probe, nu veți putea stabili ce date au fost atinse și nici nu veți putea susține raportările către autorități. O investigație digitală (DFIR) servește exact acestui scop: determină ce s-a întâmplat, cât de departe a ajuns și ce trebuie făcut.

Când devine incident „semnificativ” și ce notificări urmează

Această secțiune este o orientare generală, nu o opinie juridică; pentru cazul vostru concret consultați un jurist și documentele DNSC.

Dacă sunteți entitate esențială sau importantă conform NIS 2 (în România, OUG 155/2024, aprobată prin Legea 124/2025), incidentele semnificative se notifică DNSC în trei etape: avertizare timpurie în cel mult 24 de ore de la luarea la cunoștință, notificare cu evaluare inițială în cel mult 72 de ore și raport final în cel mult o lună de la notificarea de 72 de ore. Un incident este în general considerat semnificativ când a produs sau poate produce o perturbare operațională gravă a serviciilor ori pierderi financiare pentru entitate, sau când a afectat ori poate afecta alte persoane prin prejudicii materiale sau nemateriale considerabile. Evaluarea pragului o face entitatea, pe baza criteriilor din lege și a ghidurilor DNSC.

Termenele curg de la momentul în care organizația ia cunoștință de incident, nu de la momentul în care contractează un furnizor de investigație. Existența unei vulnerabilități neremediate nu este, prin ea însăși, un incident; un acces neautorizat confirmat sau suspectat serios poate fi.

Pe lângă DNSC, NIS 2 prevede, atunci când este cazul, informarea fără întârziere a destinatarilor serviciilor care ar putea fi afectați de incident sau de o amenințare cibernetică semnificativă, inclusiv cu măsurile pe care aceștia le pot lua. Dacă incidentul a afectat date cu caracter personal, GDPR cere în plus notificarea ANSPDCP în cel mult 72 de ore de la luarea la cunoștință, dacă este probabil să existe un risc pentru persoanele vizate, și informarea persoanelor vizate când riscul este ridicat. Aceste obligații sunt distincte și se pot suprapune.

Pentru fluxul complet de raportare, vedeți și articolul nostru despre termenele de 24 de ore, 72 de ore și o lună.

Cum vă poate ajuta REMILT

Dacă vreți să verificați dacă serverele voastre au fost compromise sau să documentați răspunsul pentru auditori, asigurători și autorități, REMILT oferă investigare digitală și răspuns la incidente (DFIR) în rețele IT și în medii industriale OT/SCADA: prezervarea probelor cu lanț de custodie, analiza incidentului, raport tehnic și, opțional, preluarea ciclului de raportare către DNSC. Pachetele, cu prețuri publice fără TVA, sunt pe pagina dedicată: intervenție IT de la 1.000 € pe zi-om, intervenție OT/SCADA de la 1.500 € pe zi-om și retainer anual pentru organizații care vor intervenție cu timp de începere garantat.

Nu promitem rezultate fixe: durata și rezultatul unei investigații depind de ce găsim. Promitem metodă, probe documentate și un raport clar. Dacă aveți un incident în desfășurare, contactați-ne direct.