Pe 21 octombrie 2026, la 13:45 ora României (6:45 la Washington), contul de securitate cibernetică al NSA, agenția americană de securitate națională, a publicat un mesaj adresat tuturor celor care folosesc PHP, tehnologia pe care rulează majoritatea site-urilor:
„Cu efect imediat, toate organizațiile care folosesc PHP sunt sfătuite să se pregătească pentru o actualizare care rezolvă două vulnerabilități critice. […] Aceste vulnerabilități oferă adesea acces direct la fișierele sau la baza de date a serverului. Dacă actualizarea imediată nu este posibilă, recomandăm ca organizațiile să scoată sistemul offline până la remedierea completă.”
NSA Cyber (@NSACyber), 21 octombrie 2026
Mesajul a strâns peste 2 milioane de vizualizări, iar sfatul a fost luat în serios. Unele instituții își opriseră deja site-urile de dimineață, altele au făcut-o în cursul zilei, iar printre ele s-au numărat parlamente, guverne, spitale și companii cunoscute în toată lumea.
Cine și-a oprit site-urile
Niciuna dintre aceste organizații nu a fost spartă. Toate au ales să rămână offline câteva ore sau o zi întreagă decât să riște, iar CERT-EU (echipa de securitate cibernetică a instituțiilor europene) și NCSC din Marea Britanie au dat același sfat ca NSA: ce nu poate fi actualizat imediat trebuie oprit.
Guverne și parlamente. În Olanda s-au oprit site-ul Camerei Reprezentanților, DigiD (sistemul prin care olandezii se autentifică la serviciile statului), MijnOverheid, portalul Overheid.nl, autoritatea de protecție a datelor și chiar Centrul Național de Securitate Cibernetică. Finlanda a oprit toate serviciile web publice ale guvernului, iar Franța toate site-urile Ministerului de Interne. Alte site-uri guvernamentale franceze au fost temporar indisponibile. În Danemarca s-a oprit platforma națională prin care școlile comunică cu părinții.
Spitale, universități și infrastructură. Spitalul universitar Charité din Berlin, Universitatea din Basel, Portul Rotterdam și numeroase spitale din Olanda și-au oprit site-urile. Cyon, o firmă de hosting din Basel, a oprit tot: portalul clienților, webmail-ul și toate site-urile găzduite.
Companii și platforme. Nintendo a oprit o parte din servicii, iar Final Fantasy XIV a suspendat autentificările noi pe toate serverele. Au căzut și alte jocuri online și magazine din Japonia. Lista continuă cu Fundația Wikimedia (numeroase servicii de suport), KNVB (Federația Olandeză de Fotbal), Tweakers, 4chan, Liquipedia, OBS Project și organizația pentru protecția vieții private noyb.
Ce este PHP2Shell
PHP este motorul pe care rulează aproximativ 70% din site-uri: blogurile și site-urile de prezentare făcute pe WordPress, multe magazine online, webmail-uri și panouri de administrare. PHP2Shell este numele dat unor erori găsite chiar în acest motor, nu în vreun site anume. De aceea nu contează cât de bine e făcut un site: dacă rulează pe o versiune vulnerabilă de PHP, e expus.
Oficial, este vorba despre două vulnerabilități, CVE-2026-109618 și CVE-2026-109619, ambele cu scorul de gravitate 9,2 din 10. Numele spune ce se poate întâmpla: „shell” înseamnă acces la linia de comandă a serverului. Cine exploatează breșa poate prelua controlul serverului fără cont și fără parolă, cu o singură cerere trimisă site-ului.
Cum a fost descoperită
Codul vulnerabil a intrat în PHP în 2012. În 2024, în timpul unui audit, un dezvoltator PHP a observat eroarea de memorie din spatele uneia dintre vulnerabilități. Echipa nu a ajuns la un acord asupra reparației și, pentru că nimeni nu demonstrase că eroarea poate fi exploatată, subiectul a rămas deschis. Problema de fond era considerată de ani de zile prea greu de exploatat ca să conteze.
În august 2026, două echipe de cercetători au arătat independent, în aceeași lună, că se poate: Calif, o firmă de securitate din California, în cadrul programului „Patch the Planet” al OpenAI, și Wiz, o firmă de securitate cloud. Ambele au folosit modele AI. Wiz a declarat că modelele AI de ultimă generație au redus mult efortul necesar pentru a transforma o astfel de breșă într-un atac funcțional. OpenAI a comentat că vulnerabilitățile „existau deja”, dar că AI-ul „îi poate ajuta și pe atacatori să le exploateze”.
Cum s-a ajuns la panică
Cercetătorii au raportat vulnerabilitățile echipei PHP, care a lucrat două luni în secret la reparație. Publicarea era planificată pentru joi, 22 octombrie.
Planul s-a stricat pe 20 octombrie, după-amiază, când o postare pe Hacker News, un forum foarte urmărit de programatori, a anunțat două vulnerabilități critice în PHP. Postarea a fost ștearsă repede, dar capturile de ecran circulau deja. A apărut și un video cu atacul, publicat din greșeală, iar firma de securitate watchTowr a confirmat că vulnerabilitățile sunt reale. În aceeași seară, echipa PHP a anunțat că actualizarea va apărea a doua zi, cu o zi mai devreme decât era planificat.
Pe 21 octombrie, la 10:34, firmele de hosting au raportat primele atacuri. La 10:43, Cloudflare, una dintre cele mai mari companii care protejează site-uri, a anunțat că vede atacuri și a activat reguli de protecție pentru toți clienții, inclusiv pentru cei de pe planul gratuit. În cursul dimineții au început să se oprească primele site-uri instituționale, iar la 13:45 a venit mesajul NSA.
Actualizarea a apărut la 17:00. Firma de securitate Sansec a estimat că atacurile în masă vor începe în aproximativ 15 minute, pentru că oricine putea compara de acum codul vechi cu cel nou și putea vedea exact ce s-a reparat.
Dacă nu ai un site
Telefonul și calculatorul tău nu sunt afectate, pentru că vulnerabilitățile sunt pe servere, nu pe dispozitivele oamenilor. Unele site-uri pe care le folosești pot fi indisponibile o perioadă, de obicei pentru că cei care le administrează au ales să le oprească până la actualizare. Fii atent la e-mailurile de tipul „Actualizare urgentă de securitate, autentifică-te aici”: escrocii profită de astfel de subiecte, iar nicio bancă sau serviciu legitim nu îți cere parola din cauza PHP2Shell. Dacă un serviciu pe care îl folosești anunță în zilele următoare o scurgere de date, schimbă-ți parola acolo și oriunde ai folosit aceeași parolă.
Pe scurt
- Gravitate: CVSS 9,2 din 10; execuție de cod de la distanță, fără autentificare.
- Versiuni afectate: PHP 5.4 – 8.5.
- Versiuni reparate: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (publicate pe 21 octombrie, la 17:00).
- PHP 8.1 și mai vechi: fără actualizare oficială.
- Atacuri: active din dimineața zilei de 21 octombrie, dinainte de apariția actualizării.
De ce sunt expuse atât de multe site-uri
Atacul are loc înainte ca aplicația să ruleze. PHP citește cererea înainte ca WordPress-ul sau magazinul tău să execute vreo linie de cod, așa că un plugin de securitate pornește prea târziu ca să intervină, iar modul de mentenanță din WordPress este ocolit complet.
Cercetătorii au confirmat atacul, cu setările implicite, pe versiuni actuale de WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, Roundcube, phpMyAdmin, Laravel, Symfony și WHMCS. Estimările vorbesc de 1,3 până la 1,9 milioane de servere care rulează PHP, sunt accesibile direct din internet și pot fi vulnerabile.
Cea mai greu de rezolvat rămâne situația versiunilor vechi. O analiză pe 7,2 milioane de site-uri PHP arată că aproape jumătate rulează pe versiuni care nu mai sunt întreținute. Un cercetător de la Detectify a explicat ce înseamnă asta în practică: „Site-urile acestea nu au mai fost actualizate de ani de zile, ceea ce înseamnă de obicei că nu le mai supraveghează nimeni.”
Cum funcționează atacul
Situația seamănă cu o cameră de hotel dată următorului client înainte de a fi fost curățată: ce a lăsat clientul anterior ajunge la cel nou. În PHP, „camera” este memoria procesului care tratează cererile, iar ce rămâne în ea după o cerere întreruptă poate fi folosit de atacator.
- CVE-2026-109618 („RCE via OOM corruption”). Atacatorul trimite o cerere de tip
multipart/form-data(formatul prin care formularele trimit fișiere), construită astfel încât PHP să rămână fără memorie chiar în timp ce o citește. PHP se oprește la jumătate, iar la curățenie tratează datele construite pe jumătate ca și cum ar fi valide. - CVE-2026-109619 („RCE via stale global state”). După o cerere întreruptă rămân în memorie date care indică spre zone deja eliberate, iar următoarea cerere preluată de același proces PHP le folosește. Pe lângă rularea de cod, breșa permite și citirea memoriei serverului, unde se pot afla parole, chei API, sesiunile utilizatorilor autentificați și chei private TLS. Cercetătorii au arătat că datele pot ajunge înapoi la atacator într-un cookie
PHPSESSID, chiar dacă site-ul nu folosește sesiuni.
Ce ai de făcut dacă ai un site
Cum afli ce versiune de PHP ai
- În WordPress: Unelte → Sănătatea site-ului → Informații → Server, la rândul „Versiune PHP”.
- În cPanel, DirectAdmin sau Plesk: secțiunea „Select PHP Version” sau „PHP Settings”.
- Pe un server administrat de tine: rulează
php -v. Versiunea din linia de comandă poate fi diferită de cea care servește efectiv site-ul prin PHP-FPM (procesele care rulează PHP pentru paginile web), așa că verifică-le pe amândouă.
Ce faci în funcție de versiune
| Versiunea ta | Situația | Ce faci |
|---|---|---|
| 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau mai nouă | ✅ Reparată | Nimic urgent. Verifică totuși dacă site-ul a fost atacat înainte de actualizare (vezi mai jos). |
| 8.2, 8.3, 8.4, 8.5, dar mai veche decât cele de mai sus | ⚠️ Vulnerabilă | Actualizează cât mai repede. Dacă ești pe hosting, cere explicit actualizarea firmei de hosting. |
| 7.4, 8.0, 8.1 | 🔴 Vulnerabilă, fără actualizare oficială | Treci pe 8.2 sau mai nou. Corecturi mai pot oferi doar distribuțiile Linux cu suport extins sau furnizorii de suport pe termen lung (LTS). |
| 5.4 – 7.3 | 🔴 Vulnerabilă, fără nicio reparație | Mută site-ul pe o versiune nouă sau oprește-l. Altă variantă nu există. |
Pentru 7.4, 8.0 și 8.1, echipa PHP a publicat doar corecturi în codul sursă, pe care trebuie să le compilezi singur. Sunt utile unui administrator de servere, dar nu cuiva care are un site pe un hosting obișnuit.
Trecerea la o versiune nouă poate strica un site vechi, cu o temă abandonată sau cu pluginuri neactualizate de ani de zile. Fă un backup înainte, verifică site-ul după mutare și asigură-te că ai pe cineva care poate repara ce nu mai merge. Un site care afișează o eroare rămâne oricum o problemă mult mai mică decât un server compromis.
Măsuri temporare până la actualizare
Măsurile de mai jos reduc riscul, dar nu înlocuiesc actualizarea. Echipa PHP spune clar că singura reparație reală este trecerea la o versiune reparată.
- Cloudflare. Dacă site-ul trece prin Cloudflare cu WAF-ul activ (firewall-ul pentru aplicații web), inclusiv pe planul gratuit, are deja reguli pentru atacurile cunoscute. Ele protejează doar traficul care trece prin Cloudflare, nu și cererile trimise direct la IP-ul serverului.
- Dezactivarea „upload progress”. În
php.inisau în configurația pool-ului PHP-FPM, cuphp_admin_valueca site-ul să nu o poată suprascrie, seteazăsession.upload_progress.enabled = 0. Pe PHP 8.5 adaugă șifatal_error_backtraces = 0. Apoi repornește procesele PHP. - Blocarea formularelor cu fișiere. Toate atacurile cunoscute folosesc cereri
multipart/form-data. Le poți bloca din serverul web sau din WAF (de exemplu ModSecurity), cu prețul că nu mai merg încărcările de fișiere: imaginile în WordPress, atașamentele din webmail, CV-urile trimise prin formular. Dacă ai un magazin online, plasează o comandă de test după ce activezi blocarea. - Pagina statică de mentenanță. Dacă nimic din cele de mai sus nu e posibil, oprește PHP și afișează un simplu fișier HTML, așa cum au procedat instituțiile care și-au oprit site-urile. Modul de mentenanță din WordPress nu ajută, pentru că rulează tot prin PHP.
Printre recomandările oficiale se află și memory_limit = -1, care închide una dintre căile de atac. Are însă un dezavantaj serios: o singură cerere poate consuma toată memoria serverului. Folosește această setare doar dacă monitorizezi serverul și știi ce faci.
Cum verifici dacă ai fost deja atacat
Atacurile au început cu câteva ore înainte de apariția actualizării, așa că un server actualizat nu e neapărat și curat. Caută următoarele semne:
- în loguri, cereri care conțin
php2shellîn User-Agent (identificatorul pe care îl trimite programul care face cererea); - multe cereri cu fișiere, urmate de erori de memorie sau de răspunsuri 500 repetate;
- cookie-uri
PHPSESSIDneobișnuit de mari sau cu conținut ciudat în răspunsurile serverului; - procese PHP care repornesc fără motiv aparent;
- fișiere PHP noi în
wp-content/uploadssau în/tmpși conturi de administrator WordPress pe care nu le-ai creat tu.
Dacă găsești oricare dintre aceste semne, tratează serverul ca fiind compromis și schimbă toate parolele și cheile care se află pe el: baza de date, conturile de e-mail, cheile API (plăți, curierat, facturare) și conturile de administrator. Una dintre vulnerabilități permite citirea memoriei, deci aceste date pot fi deja în mâinile atacatorului.
Nu uita de PHP-ul pe care nu-l vezi
Autoritatea elvețiană pentru securitate cibernetică a atras atenția că PHP rulează și în locuri pe care nu le consideri site-uri: webmail-ul, phpMyAdmin, panoul de control al hostingului, un site de test uitat pe un subdomeniu, aplicațiile interne și, uneori, chiar routere sau NAS-uri. Fă o listă cu toate și verifică fiecare sistem în parte.
Dacă ai site-uri care rulează încă pe PHP 7.4 sau pe o versiune mai veche, planifică acum mutarea pe 8.2 sau pe o versiune mai nouă: backup, test pe noua versiune, reparații. Dacă mutarea nu se poate face în zilele următoare, oprește site-ul până atunci, cum au procedat și instituțiile de mai sus.
Surse
- NSA Cyber (@NSACyber) pe X, 21 octombrie 2026, 6:45 AM
- Tenable: PHP2Shell FAQ
- Sansec: PHP2Shell, analiză tehnică și cronologie
- Patchstack: alertă și recomandări pentru WordPress
- The Register: PHP devs publish critical bug fix
- The Record: Hundreds of websites taken offline
- Help Net Security: PHP2Shell patched
- bluewin.ch: What does PHP2Shell mean?
- Roland Farkas: cronologia scurgerii
- Wikipedia: PHP2Shell
