PHP2Shell: ce trebuie să facă acum o firmă cu site PHP sau WordPress

Două vulnerabilități critice în PHP permit preluarea serverului fără parolă. Ce verifici, ce ceri hostingului și ce faci dacă nu poți actualiza azi, după pașii DNSC.

Pe 21 octombrie 2026, echipa PHP a publicat corecturi pentru două vulnerabilități critice, cunoscute public ca PHP2Shell (CVE-2026-109618 și CVE-2026-109619). Ambele au scorul 9.2 din 10 și pot permite unui atacator să ruleze cod pe server fără cont și fără parolă. PHP e limbajul pe care rulează WordPress, WooCommerce, PrestaShop, Magento, Joomla, Drupal, Laravel și multe aplicații făcute la comandă, așa că printre cei afectați e foarte probabil și site-ul firmei tale.

Articolul e pentru proprietari și manageri, nu pentru programatori. Îți spune ce să verifici, ce să ceri hostingului sau firmei care îți administrează site-ul și ce faci dacă nu se poate actualiza azi. Pașii urmează alerta publicată de DNSC, Directoratul Național de Securitate Cibernetică.

Problema nu e în tema sau în pluginurile site-ului, ci în PHP însuși, programul de pe server care execută site-ul. O cerere construită special poate strica memoria PHP în timpul procesării, iar asta poate duce la preluarea serverului. Detaliile au început să circule înainte ca fixul să fie gata. Amazon a raportat o primă tentativă de exploatare pe 17 octombrie, cu patru zile înainte de anunțul oficial.

Agențiile de securitate au dat același sfat: DNSC în România, CERT-EU pentru instituțiile europene, NCSC în Marea Britanie și FBI în Statele Unite. Actualizați PHP acum; dacă nu se poate, izolați sau opriți temporar sistemul până la remediere.

Atacurile de acest tip sunt automatizate: se scanează internetul întreg, nu se aleg ținte. Un site de prezentare cu cinci pagini e la fel de expus ca un magazin mare, iar un server preluat poate fi folosit pentru spam, pentru atacuri asupra altora sau pentru furtul datelor din formulare și din baza de date.

Un plugin de securitate nu te apără de PHP2Shell. DNSC atrage explicit atenția că pluginurile de securitate, modul de mentenanță sau dezactivarea încărcării de fișiere nu sunt protecție suficientă, pentru că intervin după ce PHP a procesat deja cererea. La fel, Cloudflare precizează că actualizarea temei sau a pluginurilor nu repară problema: trebuie actualizat PHP.

• Pe găzduire partajată (cPanel, Plesk sau panoul hostingului): versiunea PHP apare în panou. Mai sigur e să întrebi direct suportul hostingului dacă a aplicat corecturile din 21 octombrie.
• În WordPress: Unelte → Sănătate site → Informații → Server arată versiunea PHP.
• Pe un server propriu sau în cloud: cine îl administrează verifică versiunea folosită efectiv de serverul web, nu doar pe cea din linia de comandă. Distribuțiile Linux pot include fixul fără să schimbe numărul afișat, așa că se citește și buletinul de securitate al distribuției.

OpenAI a publicat o unealtă gratuită care citește versiunea PHP afișată de un site. E un prim triaj util, dar chiar documentația ei spune că un rezultat „necunoscut” nu înseamnă că site-ul e în siguranță: multe servere ascund versiunea. Răspunsul sigur vine de pe server.

Versiunile care conțin fixul, publicate pe 21 octombrie 2026, sunt:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

După actualizare trebuie repornite toate procesele PHP (de exemplu PHP-FPM), iar imaginile de container trebuie reconstruite. DNSC recomandă apoi verificarea versiunii folosite efectiv de aplicație. Fără repornire, serverul poate rula în continuare codul vechi.

Atenție la PHP 8.2: primește acum fixul, dar iese din suport pe 31 decembrie 2026. Dacă tot faci o actualizare, merită discutat saltul direct la 8.4 sau 8.5, ca să nu repeți munca peste două luni.

Proiectul PHP nu mai publică versiuni pentru 8.1, 8.0, 7.x sau mai vechi. Echipa PHP a pus la dispoziție corecturi minimale pentru 7.4, 8.0 și 8.1, dar ele trebuie compilate din cod sursă. Unele distribuții Linux și furnizori de suport extins oferă pachete corectate.

Pentru cele mai multe firme, varianta realistă e migrarea la o versiune suportată. La un site WordPress actualizat de curând, de obicei e o schimbare în panoul hostingului, urmată de teste. La o aplicație veche, scrisă pentru PHP 5 sau 7, e un mic proiect: codul trebuie adaptat și testat înainte de mutare. Până atunci, DNSC recomandă izolarea sistemului sau măsuri temporare.

Echipa PHP spune clar că nu există o atenuare completă: doar actualizarea rezolvă problema. Pentru câteva zile, cine administrează serverul poate reduce totuși riscul:

• dezactivează funcția „session upload progress” din configurația PHP și repornește procesele;
• limitează dimensiunea și numărul câmpurilor din cererile primite de server;
• blochează încărcările de fișiere acolo unde site-ul nu are nevoie de ele;
• pune site-ul în spatele unui firewall de aplicație (WAF), de exemplu Cloudflare, care a publicat reguli pentru PHP2Shell. DNSC precizează că un WAF ajută doar dacă serverul nu poate fi accesat direct, ocolind filtrul.

Dacă nici asta nu e posibil, NCSC și FBI recomandă scoaterea temporară a sistemului de pe internet până la remediere. Pentru un site de prezentare, o pagină statică temporară e adesea o soluție bună.

Pentru că tentativele au început înainte de patch, actualizarea nu ajunge singură. DNSC recomandă căutarea semnelor de compromitere începând cu 20 octombrie 2026, ora 15:00 UTC (18:00, ora României):

• fișiere noi sau modificate în directoarele site-ului;
• modificări în fișierele .user.ini sau în setarea auto_prepend_file;
• sarcini programate (cron) sau chei SSH noi;
• procese de tip shell sau programe de descărcare pornite de PHP;
• conturi noi de administrator în aplicație.

Dacă găsești ceva, serverul se izolează, jurnalele se păstrează, sistemul se reinstalează din surse curate și se schimbă toate parolele, cheile și secretele la care PHP avea acces. Incidentul se poate raporta la DNSC, la numărul 1911.

Pentru WordPress, încă o verificare. În aceeași săptămână, atacatorii au folosit cheile UpdraftCentral furate de la producătorul pluginului UpdraftPlus ca să instaleze pluginuri ascunse și conturi noi pe site-uri altfel actualizate. Dacă folosești UpdraftPlus, actualizează-l, șterge cheile UpdraftCentral din setări și verifică lista de utilizatori.

DNSC amintește că, potrivit Legii nr. 58/2023, art. 5 lit. a), responsabilitatea pentru securitatea unui sistem informatic revine persoanei sau firmei care îl deține, îl administrează sau îl folosește. Practic, chiar dacă site-ul a fost făcut de altcineva acum câțiva ani, firma ta trebuie să se asigure că e actualizat. Pentru obligațiile exacte în cazul tău, verifică cu un jurist.

1. Află versiunea PHP folosită efectiv de site, de la hosting sau de la administrator.
2. Actualizează la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 și repornește procesele PHP.
3. Dacă ești pe 8.1 sau mai vechi, planifică migrarea și izolează sistemul până atunci.
4. Dacă nu poți actualiza azi, aplică măsurile temporare sau oprește temporar site-ul.
5. Caută semnele de compromitere din 20 octombrie încoace.
6. Pe WordPress, verifică și UpdraftPlus și utilizatorii cu drept de administrare.

La ME Digital ajutăm firmele să aplice corecturile oficiale: verificăm versiunea reală de pe server, actualizăm sau migrăm aplicațiile vechi și căutăm semnele de compromitere. Totul face parte din serviciile de securitate și actualizări. Dacă vrei să ne uităm la site-ul tău, scrie-ne.

• PHP, anunțul de securitate din 21 octombrie 2026
• DNSC, Alertă: vulnerabilități critice în PHP (actualizată pe 22 octombrie 2026)
• CERT-EU, Security Advisory 2026-018
• NCSC (Marea Britanie), Critical security issue affecting PHP
• PHP Foundation, raportul despre lansarea de securitate din 21 octombrie 2026
• Cloudflare, protecția WAF pentru vulnerabilitățile PHP
• The Hacker News, tentativa de exploatare din 17 octombrie raportată de Amazon
• OpenAI, php2shell-checker
• Patchstack, compromiterea cheilor UpdraftCentral