Au fost descoperite vulnerabilități critice în PHP care îți pot afecta magazinul online. Site-ul tău rulează pe PHP 8.1 sau mai vechi?

Un site sau un magazin online care rulează pe o versiune PHP neactualizată poate fi accesat neautorizat prin exploatarea a două vulnerabilități critice. PHP este limbajul de programare în care sunt scrise platforme populare precum WordPress sau Magento. Echipa PHP a reparat vulnerabilitățile pe 21 octombrie 2026, în versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și versiunile mai vechi, echipa nu mai publică versiuni noi. Actualizările din WordPress și din pluginuri nu schimbă versiunea PHP. Pe un hosting partajat, actualizarea o face firma de hosting, iar pe un server propriu, cine îl administrează. Directoratul Național de Securitate Cibernetică (DNSC) recomandă actualizarea imediată și consideră orice server PHP neactualizat și expus în Internet „la risc ridicat de compromitere”. Autoritatea pentru protecția datelor (ANSPDCP) a amendat în iulie 2026 cu 78.570 de lei un magazin online atacat informatic, printre altele pentru că platforma site-ului nu era la versiunea oficială a producătorului.

Ce este PHP și de ce depinde magazinul tău online de el?

PHP este limbajul de programare în care sunt scrise multe platforme pentru site-uri și magazine online, dar și numeroase site-uri dezvoltate la comandă. Printre platformele cunoscute scrise în PHP se numără:

• WordPress, platformă de site-uri în care magazinul online se construiește cu un plugin, precum WooCommerce, scris tot în PHP;
• Magento (Adobe Commerce), platformă de magazin online;
• PrestaShop, platformă de magazin online;
• OpenCart, platformă de magazin online;
• Shopware, platformă de magazin online;
• Joomla și Drupal, platforme pentru site-uri de prezentare și portaluri.

Orice site care rulează pe PHP, de pe aceste platforme sau de pe altele, depinde de versiunea PHP instalată pe server.

Codul PHP rulează pe server, adică pe calculatorul firmei de hosting unde stă site-ul, și construiește pagina în momentul în care un vizitator o deschide, potrivit manualului oficial PHP. Clientul primește doar pagina rezultată și nu vede codul care a generat-o.

Un exemplu: când un client pune un produs în coș pe un magazin WooCommerce, codul PHP citește prețul și stocul din baza de date, calculează totalul și afișează pagina coșului. Același mecanism funcționează la fiecare căutare, la fiecare comandă trimisă și la fiecare autentificare în contul de client.

PHP este folosit de 69,3% dintre site-urile al căror limbaj de server se cunoaște, potrivit W3Techs, la 23 octombrie 2026. Limbajul este gratuit și cu sursă deschisă (open source), potrivit manualului oficial PHP.

Fiecare versiune de PHP primește corecturi de securitate pentru o perioadă limitată, la fel ca versiunile de Windows sau de sistem de operare ale telefonului. PHP 8.3, de exemplu, a apărut pe 23 noiembrie 2023 și primește corecturi de securitate până pe 31 decembrie 2027, potrivit calendarului oficial de suport. După această dată, versiunea continuă să funcționeze, dar breșele descoperite ulterior nu mai sunt reparate de echipa PHP.

De ce te privește vulnerabilitatea PHP2Shell dacă ai un magazin online?

Orice site sau magazin online care rulează pe PHP rămâne expus până la actualizarea PHP de pe server, indiferent de platformă: WordPress cu WooCommerce, Magento, PrestaShop sau un site dezvoltat la comandă. Cele două vulnerabilități, înregistrate în catalogul internațional de vulnerabilități ca CVE-2026-109618 și CVE-2026-109619 și cunoscute public sub numele PHP2Shell, pot permite execuția de cod la distanță fără autentificare, potrivit anunțului de securitate publicat de echipa PHP pe 21 octombrie 2026. În practică, un atacator poate rula propriile comenzi pe server fără cont și fără parolă. Ambele vulnerabilități au scorul 9,2 din 10 pe scala de gravitate CVSS v4.0, potrivit preanunțului PHP din 20 octombrie.

Sunt afectate toate instalările PHP care servesc pagini web, inclusiv configurațiile PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed, potrivit echipei PHP. Riscul cel mai mare apare la mod_php, unde există un atac demonstrat care pornește înainte ca site-ul să ruleze vreo linie din propriul cod, potrivit aceleiași surse.

Primele încercări de exploatare au apărut pe 17 octombrie, cu patru zile înainte de publicarea corecturilor, potrivit Amazon, citat de BleepingComputer. Pe 21 octombrie, primele coduri demonstrative de atac începuseră deja să circule public, ceea ce face exploatarea mai probabilă, potrivit avizului 2026-018 al CERT-EU, echipa de securitate cibernetică a instituțiilor UE. Pe 22 octombrie, firma de analiză Dataminr nu raporta nicio compromitere reușită confirmată, potrivit aceleiași publicații BleepingComputer. Autoritățile din Țările de Jos, Danemarca, Finlanda și Franța au scos offline o parte din site-urile publice, potrivit Capital.

A treia vulnerabilitate PHP, anunțată pe 23 octombrie, îți afectează magazinul?

Pentru cele mai multe magazine, nu, dar merită o întrebare în plus către firma de hosting. Pe 23 octombrie 2026, echipa PHP a publicat un aviz informativ despre o a treia vulnerabilitate, CVE-2026-115560, pe care o descrie drept „un vector de execuție de cod la distanță puțin probabil” („an unlikely RCE vector”), potrivit avizului de pe php.net. Problema apare doar într-o combinație neobișnuită de configurare și cod: aplicația trebuie să schimbe la rulare modul în care salvează sesiunile și să aibă activată funcția de afișare a progresului la încărcarea fișierelor (session upload progress). Aplicațiile care nu schimbă acest mod la rulare pot lăsa funcția activă, potrivit aceluiași aviz.

Versiunile din 21 octombrie nu repară această a treia problemă. Echipa PHP nu publică o corectură de urgență pentru ea, ci o va include în următoarea versiune de rutină, împreună cu avizul complet. Până atunci recomandă dezactivarea funcției session upload progress (setarea session.upload_progress.enabled=0), aceeași măsură pe care o listase pe 21 octombrie pentru CVE-2026-109619. Nicio exploatare a acestei vulnerabilități nu fusese raportată la 23 octombrie, potrivit The Hacker News. Setarea se face pe server, deci pe o găzduire partajată o aplică firma de hosting.

Cine actualizează PHP pe site-ul tău: firma de hosting, agenția sau tu?

Actualizarea PHP o face cine administrează serverul pe care stă site-ul. Cine anume face acest lucru depinde de tipul de găzduire. PHP este instalat pe server, așa că versiunea lui se schimbă din setările găzduirii sau la cererea către furnizor, potrivit WordPress.org. Actualizările automate din WordPress, din temă și din pluginuri nu modifică versiunea PHP.

Cine face actualizarea, în funcție de găzduire:

• găzduire partajată (shared hosting): firma de hosting instalează versiunile reparate pe servere. Multe firme de hosting îți permit să alegi singur, din panoul de control, ce versiune PHP folosește site-ul, potrivit WordPress.org;
• server virtual (VPS) sau server propriu: actualizarea revine celui care administrează serverul, adică ție, unui angajat IT sau agenției, dacă asta prevede contractul cu ea;
• platformă de magazin online pe abonament (SaaS): responsabilitatea pentru infrastructură și actualizările tehnice trece la furnizorul platformei, potrivit ghidului Protecției Consumatorilor (ANPC) pentru comerțul online, ediția 2026. Tu rămâi răspunzător pentru componentele personalizate.

Răspunderea pentru securitatea unui sistem informatic revine persoanei fizice sau juridice care îl deține, îl organizează, îl administrează sau îl utilizează, potrivit art. 5 lit. a) din Legea nr. 58/2023, citat de DNSC în alerta din 21 octombrie 2026. Interpretarea noastră: faptul că firma de hosting face tehnic actualizarea nu te scutește, ca proprietar al magazinului, de grija de a verifica dacă s-a făcut.

Pluginurile de securitate, modul de mentenanță și verificările de autentificare din aplicație nu trebuie considerate o protecție suficientă împotriva acestor vulnerabilități, pentru că pot interveni după ce PHP a procesat deja cererea, avertizează DNSC în aceeași alertă. Singura protecție completă rămâne actualizarea, potrivit echipei PHP: „There are no complete mitigations, updating is the only safe choice” („Nu există măsuri complete de atenuare, actualizarea este singura opțiune sigură”).

Cum afli ce versiune PHP rulează site-ul tău?

În WordPress, versiunea PHP apare în meniul Unelte (Tools), la Sănătatea site-ului (Site Health), în fila Informații (Info), secțiunea Server, potrivit WordPress.org. Dacă nu folosești WordPress, o poți afla din panoul de control al găzduirii, când firma de hosting îl oferă, sau direct de la firma de hosting.

Compară versiunea găsită cu tabelul de mai jos, construit pe baza anunțului PHP și a calendarului oficial de suport:

Numărul afișat poate induce în eroare. Distribuțiile Linux pot include corectura într-un pachet fără să schimbe numărul versiunii PHP afișate, potrivit DNSC. Dacă site-ul arată o versiune mai veche decât cele din tabel, cere confirmarea scrisă a firmei de hosting înainte să tragi o concluzie.

DNSC recomandă și repornirea tuturor proceselor PHP după actualizare, plus verificarea versiunii folosite efectiv de aplicație. Pe găzduirea partajată, ambii pași revin firmei de hosting.

Ce faci dacă site-ul rulează PHP 8.1 sau o versiune mai veche?

Pentru PHP 8.1 și versiunile mai vechi, echipa PHP nu publică versiuni noi, potrivit anunțului din 21 octombrie. Echipa a pus la dispoziție în codul sursă doar corecturi minime pentru 7.4, 8.0 și 8.1, pe care furnizorii le pot integra, potrivit BleepingComputer. Unele distribuții Linux și unii furnizori de suport extins (LTS) oferă corecturi adaptate pentru versiunile vechi, așa că primul pas este să întrebi firma de hosting dacă le-a aplicat. DNSC recomandă ca instalările ieșite din suport să fie corectate prin aceste corecturi adaptate (backport-uri), izolate și migrate cu prioritate la o versiune între PHP 8.2 și 8.5.

Situația e frecventă. 26,9% dintre site-urile pe PHP rulează încă versiunea 7 și 7,7% versiunea 5, potrivit W3Techs. Dintre site-urile pe PHP 8, 15,1% rulează 8.1 și 5,8% rulează 8.0, potrivit aceleiași surse. Calculul nostru pe aceste date arată că aproape jumătate dintre site-urile pe PHP folosesc o versiune fără suport oficial. W3Techs vede doar numărul afișat al versiunii, nu și corecturile adaptate instalate de unii furnizori.

WordPress și WooCommerce recomandă PHP 8.3 sau mai nou, potrivit cerințelor WordPress și cerințelor de server WooCommerce, care precizează că WooCommerce e testat până la PHP 8.4. O temă sau un plugin vechi poate să nu funcționeze după trecerea la o versiune nouă.

Recomandarea noastră: cere agenției sau firmei de hosting să testeze migrarea pe o copie a site-ului (mediu de test) înainte de a o aplica pe magazinul real. Dacă tot faci migrarea, mergi direct pe PHP 8.3 sau 8.4, nu pe 8.2, care iese din suport pe 31 decembrie 2026.

Cum îi ceri firmei de hosting sau agenției confirmarea actualizării PHP?

Un mesaj scurt, cu întrebări la care se poate răspunde punctual, îți aduce o confirmare scrisă pe care o poți păstra. Întrebările de mai jos pornesc de la recomandările DNSC din alerta din 21 octombrie 2026 și de la avizul PHP din 23 octombrie 2026.

Bună ziua, >Pentru site-ul [adresa site-ului], vă rog să-mi confirmați în scris: >1. Ce versiune PHP rulează acum site-ul și dacă include corecturile pentru CVE-2026-109618 și CVE-2026-109619 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau o corectură adaptată de la furnizorul sistemului de operare).2. La ce dată ați aplicat actualizarea și dacă procesele PHP au fost repornite.3. Dacă ați verificat serverul pentru semne de compromitere începând cu 20 octombrie 2026, ora 18:00 (ora României): fișiere noi sau modificate în directoarele site-ului, conturi noi de administrator, sarcini programate noi.4. Dacă site-ul rulează PHP 8.1 sau o versiune mai veche, ce plan aveți pentru migrare și până la ce dată.5. Dacă funcția session upload progress este dezactivată pe server (session.upload_progress.enabled=0), așa cum recomandă echipa PHP din 23 octombrie, până la următoarea versiune de rutină. >Mulțumesc,[nume, firmă]

Intervalul de la punctul 3 vine din alerta DNSC, care recomandă verificarea posibilelor compromiteri produse începând cu 20 octombrie 2026, ora 15:00 UTC (18:00, ora României). Dacă apar indicii de compromitere, DNSC recomandă izolarea serverului, păstrarea jurnalelor, reinstalarea sistemului din surse de încredere și schimbarea parolelor și a cheilor la care procesul PHP avea acces.

Recomandarea noastră: păstrează răspunsul primit împreună cu data. Te ajută să arăți, la un eventual control, ce măsuri de securitate aveai.

Riști amendă GDPR dacă atacatorii intră pe site printr-o versiune PHP neactualizată?

Da, dacă atacatorii ajung la datele personale ale clienților sau ale angajaților și nu poți arăta măsuri de securitate adecvate riscului, cerute de art. 32 din Regulamentul general privind protecția datelor (GDPR). Același articol cere, la alin. (1) lit. d), un proces de testare și evaluare periodică a eficacității acestor măsuri.

Homelux SRL, firmă cu magazin online, a primit pe 31 iulie 2026 o amendă de 78.570 de lei pe art. 32 din GDPR, după un atac informatic, potrivit comunicatului ANSPDCP. Autoritatea a constatat că platforma site-ului nu corespundea tehnic versiunii oficiale lansate de producător și a găsit cerințe slabe pentru parole.

Între 31 iulie și 16 octombrie 2026, ANSPDCP a amendat pe art. 32 cinci firme atacate informatic, cu 178.279,50 lei în total. Cel mai recent caz privește MyConnector Platform SRL, amendată cu 31.451 de lei, potrivit comunicatului din 16 octombrie. Primele patru cazuri le găsești explicate în Ești atacat cibernetic și pierzi datele clienților?.

Pentru încălcarea art. 32, amenda poate ajunge la 10 milioane de euro sau 2% din cifra de afaceri anuală mondială, valoarea mai mare dintre ele, potrivit art. 83 alin. (4) din GDPR. Cele cinci amenzi din 2026 au rămas mult sub acest plafon.

Dacă un incident afectează datele personale și poate genera un risc pentru persoanele vizate, ai 72 de ore să anunți ANSPDCP, potrivit art. 33 din GDPR. Pașii, oră cu oră, sunt în Ce faci în primele 72 de ore după o breșă de date. Incidentele de securitate cibernetică se pot raporta la DNSC prin platforma PNRISC sau la numărul unic 1911.

Ce ai de verificat până la Black Friday și până pe 31 decembrie 2026?

Până pe 6 noiembrie, când începe Black Friday 2026 la eMAG, cel mai mare retailer online din România, află versiunea PHP a site-ului, cere confirmarea scrisă a firmei de hosting și verifică dacă au apărut conturi noi de administrator. Până pe 31 decembrie 2026, când PHP 8.2 iese din suport, potrivit php.net, planifică trecerea pe PHP 8.3 sau 8.4.

0 din 7 bifate

• Află ce versiune PHP rulează site-ul (în WordPress, Unelte > Sănătatea site-ului > Informații > Server)
• Trimite firmei de hosting sau agenției mesajul de mai sus și păstrează răspunsul scris
• Verifică în panoul de administrare al magazinului dacă au apărut conturi noi de administrator după 20 octombrie 2026
• Fă o copie de siguranță a site-ului și a bazei de date și verifică dacă o poți restaura
• Dacă rulezi PHP 8.1 sau o versiune mai veche, stabilește cu agenția data migrării, testată întâi pe o copie a site-ului
• Dacă rulezi PHP 8.2, planifică trecerea la PHP 8.3 sau 8.4 înainte de 31 decembrie 2026
• Termină verificările tehnice înainte de 6 noiembrie, când crește traficul de Black Friday

Verifică automat toate cele 18 reguli

Celelalte măsuri de securitate pentru un magazin online sunt în 9 măsuri de securitate pentru magazinul tău online, plus cine este obligat să raporteze incidentele. Ce verifică Protecția Consumatorilor la campaniile de reduceri găsești în Black Friday 2026: ce verifică ANPC la reducerile magazinului tău.

Surse

• Anunțul de securitate PHP: „Critical remote code execution vulnerabilities, update now”, php.net, 21 octombrie 2026
• Preanunțul echipei PHP despre actualizarea de securitate, php.net, 20 octombrie 2026
• Avizul informativ PHP „Session upload progress” (CVE-2026-115560), php.net, 23 octombrie 2026
• Avizul GHSA-w8hw-w9fx-j79w (CVE-2026-109618) și avizul GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), GitHub, 21 octombrie 2026
• Calendarul versiunilor PHP suportate, php.net
• Alerta DNSC „Vulnerabilități critice în PHP”, cu actualizarea din 22 octombrie 2026, Directoratul Național de Securitate Cibernetică
• Avizul de securitate CERT-EU 2026-018, 21 octombrie 2026
• Regulamentul (UE) 2016/679 (GDPR), art. 32, 33 și 83
• Legea nr. 58/2023 privind securitatea și apărarea cibernetică a României, art. 5 lit. a)
• Comunicatul ANSPDCP din 31 iulie 2026 (Homelux SRL) și comunicatul din 16 octombrie 2026 (MyConnector Platform SRL)
• Ghidul ANPC de bune practici pentru comerțul online, ediția 2026
• Cum actualizezi PHP și cerințele de server WordPress, WordPress.org
• Cerințele de server WooCommerce
• Statistici de utilizare PHP, W3Techs, 23 octombrie 2026
• Amazon says PHP2Shell exploitation began 4 days before patches și PHP ships emergency patches for critical PHP2Shell flaws, BleepingComputer, 21-22 octombrie 2026
• PHP Warns of Another Unpatched RCE Two Days After Emergency PHP2Shell Patches, The Hacker News, 23 octombrie 2026

Informațiile despre versiuni, corecturi și exploatare sunt valabile la 23 octombrie 2026. Corectura și avizul complet pentru CVE-2026-115560 ar urma să apară odată cu următoarea versiune de rutină PHP, fără o dată anunțată.

Acest articol are caracter informativ și nu reprezintă consultanță juridică sau tehnică. Pentru situația specifică a magazinului tău, verifică împreună cu firma de hosting sau cu un specialist în securitate.