Astăzi, 21 octombrie 2026, mai multe publicații au anunțat o problemă de securitate care ar putea afecta milioane de site-uri din întreaga lume. Unele instituții și-au închis preventiv paginile web, iar administratorii serverelor au fost îndemnați să instaleze urgent actualizări.
La prima vedere, știrea pare una dintre acelea care anunță periodic sfârșitul Internetului. Numai că, de data aceasta, chiar avem o problemă serioasă.
Nu este vorba despre o vulnerabilitate obișnuită dintr-un plugin WordPress, ci despre două erori din PHP, limbajul pe care funcționează milioane de site-uri.
Și există o diferență enormă între cele două situații.
Ce este PHP2Shell și de ce este atât de periculos?
Problema a primit numele PHP2Shell și cuprinde două vulnerabilități identificate oficial astfel:
- CVE-2026-109618 – o problemă de gestionare a memoriei atunci când PHP rămâne fără memoria necesară procesării unei cereri.
- CVE-2026-109619 – o problemă prin care anumite date interne pot rămâne accesibile după eliberarea memoriei, fiind reutilizate incorect la procesarea altor cereri.
Nu intru prea adânc în explicațiile tehnice, dar esențial este următorul lucru: în anumite condiții, un atacator poate trimite cereri special construite către un server vulnerabil și poate ajunge să execute propriul cod pe acel server.
Acest tip de atac se numește Remote Code Execution (RCE).
Și este una dintre cele mai periculoase categorii de vulnerabilități.
De ce? Pentru că atacatorul nu trebuie neapărat să cunoască parola administratorului WordPress, să descopere un plugin vulnerabil sau să se autentifice în site.
Problema poate apărea chiar înainte ca aplicația PHP să înceapă să execute codul propriu-zis.
În funcție de configurația serverului și de drepturile procesului PHP, consecințele pot include furtul datelor, modificarea fișierelor, instalarea unor programe malițioase sau compromiterea altor servicii.
Asta nu înseamnă că orice atacator primește automat controlul complet asupra întregului server. Dar riscul este suficient de mare pentru a justifica actualizări de urgență.
Ce versiuni PHP sunt vulnerabile?
Aici ajungem la informația pe care multe știri o trec prea repede cu vederea.
Pe 21 octombrie 2026, echipa oficială PHP a publicat patru versiuni care corectează cele două vulnerabilități.
| Versiune PHP | Situație |
|---|---|
| PHP 8.5.11 și anterioare din ramura 8.5 | Vulnerabile |
| PHP 8.5.12 | Corectată |
| PHP 8.4.26 și anterioare din ramura 8.4 | Vulnerabile |
| PHP 8.4.27 | Corectată |
| PHP 8.3.35 și anterioare din ramura 8.3 | Vulnerabile |
| PHP 8.3.36 | Corectată |
| PHP 8.2.34 și anterioare din ramura 8.2 | Vulnerabile |
| PHP 8.2.35 | Corectată |
| PHP 8.1 și versiunile mai vechi | Necesită actualizare, migrare sau patch de securitate furnizat separat |
Atenție: dacă ai PHP 8.3, asta nu înseamnă automat că ești protejat. Trebuie să ai cel puțin PHP 8.3.36 sau o versiune corectată de furnizorul găzduirii.
Aceeași regulă se aplică pentru PHP 8.2, 8.4 și 8.5.
Versiunile foarte vechi sunt o problemă suplimentară. Cercetătorii Wiz arată că vulnerabilitățile descoperite afectează inclusiv generații PHP lansate cu mulți ani în urmă, până la PHP 5.4, cel puțin pentru una dintre probleme.
Totuși, trebuie făcută o precizare: un furnizor de hosting poate instala corecții de securitate într-o versiune PHP mai veche, fără să-i schimbe numărul principal. Acest procedeu se numește backporting.
Așadar, simplul număr al versiunii nu este întotdeauna suficient pentru a stabili dacă un server a fost protejat.
Care versiune PHP este cea mai periculoasă?
Nu putem spune că PHP 8.2 este automat mai periculos decât PHP 8.4 sau invers.
Ceea ce contează este dacă versiunea respectivă a primit corecțiile și cum este configurat serverul.
Echipa PHP a atras însă atenția asupra unui aspect important: riscul este considerat deosebit de ridicat pentru serverele care folosesc Apache cu mod_php, unde a fost demonstrat un scenariu de exploatare fără autentificare, înainte de executarea codului aplicației.
Sunt vizate și alte moduri de executare PHP, inclusiv PHP-FPM, CGI, LiteSpeed și FrankenPHP.
Cu alte cuvinte, nu este suficient să spunem că un server este sigur pentru că folosește LiteSpeed sau PHP-FPM.
Actualizarea rămâne necesară.
Este WordPress vulnerabil?
Da, site-urile WordPress care rulează pe versiuni PHP afectate sunt expuse riscului.
Dar trebuie înțeles un lucru: nu WordPress este cauza acestei vulnerabilități.
Poți avea WordPress actualizat, o temă impecabilă, toate pluginurile la zi și parole foarte puternice. Dacă serverul execută o versiune PHP vulnerabilă, problema poate exista în continuare.
De aceea, instalarea ultimei versiuni WordPress nu rezolvă PHP2Shell.
Este necesară actualizarea mediului PHP de pe server.
Același lucru este valabil pentru Joomla, Drupal, Magento, aplicațiile Laravel și numeroase scripturi PHP dezvoltate independent.
Cât de gravă este vulnerabilitatea, în realitate?
Cele două probleme au primit un scor de severitate de 9,2 din 10 în sistemul CVSS 4.0.
Asta le plasează în categoria vulnerabilităților critice.
Dar un scor de 9,2 nu înseamnă că 92% dintre servere pot fi sparte și nici că toate site-urile care folosesc PHP au fost compromise.
Trebuie separate trei lucruri:
1. Vulnerabilitatea există. Acest lucru este confirmat oficial și au fost publicate actualizări de securitate.
2. Un server neactualizat poate fi expus. Gradul concret de expunere depinde de versiune, configurație și măsurile de protecție.
3. Existența vulnerabilității nu demonstrează că serverul a fost deja atacat. Pentru asta sunt necesare dovezi din jurnalele de securitate și investigații tehnice.
Totuși, având în vedere că PHP este folosit pe o proporție foarte mare a site-urilor, impactul potențial este enorm.
Nu este nevoie ca toate serverele să fie vulnerabile pentru ca problema să devină una globală.
De ce au fost închise site-uri în Germania și în alte țări?
Mai multe instituții europene au preferat să-și dezactiveze temporar serviciile web, în loc să riște exploatarea vulnerabilităților.
Printre exemplele relatate se numără site-ul municipalității Dresda și serviciile online ale spitalului universitar Charité din Berlin.
Aceste închideri preventive nu trebuie confundate cu atacuri informatice reușite.
Faptul că o instituție și-a oprit site-ul poate însemna pur și simplu că administratorii au decis să aștepte instalarea și verificarea actualizărilor.
Din punctul meu de vedere, pentru un serviciu care gestionează informații sensibile, o întrerupere temporară este preferabilă unei compromiteri a serverului.
Cum verifici ce versiune PHP folosește site-ul tău?
Dacă ai un site găzduit pe cPanel, verificarea este relativ simplă.
Intră în cPanel și caută opțiunea MultiPHP Manager sau Select PHP Version, în funcție de configurația furnizorului.
Acolo vei vedea versiunea PHP asociată domeniului.
Dacă folosești WordPress, poți verifica și din:
Instrumente → Sănătate site → Informații → Server → Versiune PHP.
Atenție însă: această informație arată versiunea folosită de site, nu garantează că furnizorul a instalat toate patch-urile de securitate.
Pentru o verificare completă, întreabă firma de hosting dacă a aplicat corecțiile pentru CVE-2026-109618 și CVE-2026-109619.
Dacă găzduirea este de tip shared sau reseller, de regulă nu poți instala singur actualizările PHP la nivel de server. Acest lucru trebuie făcut de administratorul infrastructurii.
Ce trebuie să faci imediat?
În primul rând, verifică versiunea PHP și disponibilitatea actualizărilor.
Dacă folosești o versiune vulnerabilă, solicită instalarea unei versiuni corectate. Înaintea schimbării versiunii principale PHP, fă un backup și verifică compatibilitatea aplicației.
Dacă ai un magazin online sau un site care prelucrează date personale, acordă prioritate actualizării și verificării jurnalelor de acces.
Nu te baza exclusiv pe un plugin de securitate WordPress sau pe un firewall de aplicație. Acestea pot oferi protecție suplimentară, dar nu înlocuiesc actualizarea PHP.
Echipa oficială PHP avertizează că nu există o metodă alternativă care să elimine complet riscul fără aplicarea corecțiilor.
În cazul unui server administrat de tine, trebuie actualizate și repornite serviciile PHP corespunzătoare, astfel încât procesele vechi să nu continue să ruleze cod vulnerabil.
Dar cei care folosesc PHP pe hosting cPanel?
Există și o veste bună.
cPanel a publicat propriul avertisment de securitate și a anunțat pachete corectate pentru EasyApache 4, inclusiv pentru PHP 7.4, 8.0 și 8.1.
Asta înseamnă că anumite versiuni vechi pot primi corecții furnizate de cPanel, chiar dacă nu mai beneficiază de suportul obișnuit al proiectului PHP.
Dar disponibilitatea unui pachet corectat nu înseamnă automat că furnizorul tău l-a instalat.
De aceea, confirmarea de la firma de găzduire este importantă.
Concluzie: este cazul să ne panicăm?
Nu. Dar este cazul să acționăm rapid.
PHP2Shell este o vulnerabilitate reală, critică și neobișnuit de serioasă, pentru că afectează componente interne ale limbajului PHP, nu doar o anumită aplicație.
Pentru administratorii de site-uri, principala măsură este simplă: actualizarea PHP la o versiune corectată și confirmarea aplicării patch-urilor pe server.
Pentru utilizatorul obișnuit, care doar citește știri sau face cumpărături online, nu există o actualizare PHP de instalat pe telefon sau calculator. Responsabilitatea protejării serverelor revine operatorilor site-urilor.
Internetul nu se prăbușește, dar milioane de administratori au primit astăzi un motiv foarte serios să-și verifice serverele.
Și, de data aceasta, nu este o actualizare pe care aș amâna-o până mâine.
Surse și documentație
- PHP.net – anunțul oficial și versiunile corectate
- Wiz Research – analiza tehnică PHP2Shell
- NCSC UK – avertismentul de securitate
- cPanel – actualizări pentru CVE-2026-109618 și CVE-2026-109619
- Digi24 – relatarea privind închiderea preventivă a unor site-uri




