Atacatori exploatează breșele din PHP: ce să ceri firmei de hosting

Cum afectează breșurile PHP firmele mici din România?

Breșe critice în PHP: ghid practic pentru proprietarii de magazine online

Pentru oricui gestionează o prezență digitală, știrea că hackerii exploatează activ două vulnerabilități grave descoperite recent în PHP este o alarmă de urgență.

Aceste defecte au fost clasificate de agenția americană CISA ca fiind deja utilizate în atacuri reale.

Cu aproximativ o săptămână rămânând până la evenimentul comercial Black Friday, proprietarii de magazine online din România, mulți dintre ei construiți pe platforme precum WooCommerce, PrestaShop sau OpenCart, se află într-o poziție delicată.

PHP rămâne motorul din spatele unei proporții semnificative a web-ului; conform datelor W3 Techs, la data de 28 octombrie, acest limbaj susținea 69,2% dintre site-urile cu tehnologie identificabilă.

Ce se întâmplă tehnic și de ce contează acum

Două defecte, identificate prin codurile CVE-2026-109618 și CVE-2026-109619, au fost reparate prin lansarea, pe 21 octombrie, a versiunilor 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Nivelul de gravitate este extrem de ridicat, evaluat la 9,2 din 10 pe scara standard. În anumite condiții, aceste breșe permit rularea de cod arbitrar pe server, fără necesitatea unei parole. Echipa de dezvoltare a subliniat că sunt afectate toate instalările care servesc pagini web, inclusiv varianta PHP-FPM, folosită masiv în mediul de hosting. Riscul maxim îl poartă serverele care rulează cu Apache și modulul mod_php.

Primele semne de exploatare au fost capturate de compania watchTowr încă din 21 octombrie, prin monitorizarea serverelor-capcană. Centrul canadian pentru securitate cibernetică a actualizat o alertă pe 27 octombrie, confirmând existența informațiilor publice despre atacuri efective. Estimările firmei Palo Alto Networks, publicate pe 23 octombrie, indicau că peste 22,6 milioane de instalări PHP accesibile public pe internet erau expuse la risc.

Impactul pentru firmele mici din România

Pentru o firmă mică, o compromitere înseamnă mult mai mult decât un simplu downtime. Datele clienților pot fi furate, paginile de plată pot fi alterate sau tot site-ul se poate bloca în cel mai rău moment, adică în perioada de vârf a vânzărilor.

eMAG, platforma de marketplace, își demarează campania de Black Friday pe 6 noiembrie, iar conform declarațiilor directorului general Tudor Manea, raportate de Wall-Street. ro, se așteaptă ca vânzările să depășească un miliard de lei.

Costul unui incident de securitate este semnificativ: raportul IBM din iulie stabilește o medie globală de 4,99 milioane de dolari per caz.

Deși un magazin mic nu pierde această sumă exactă, fondurile se consumă pe aceleași categorii: pierderi de venituri pe zilele fără acces, costuri de refacere a site-ului, onorarii de avocați și pierderea fiduciei clienților.

Ce trebuie să ceri concret de la furnizorul tău?

Legislația europeană impune responsabilități clare. În temeiul GDPR, dacă atacatorii au accesat, modificat sau blocat datele clienților, operatorul datelor este obligat să notifice Autoritatea Națională pentru Protecția Datelor Personale (ANSPDCP) în termen de cel mult 72 de ore de la constatarea incidentului.

Excepție se face doar dacă riscul pentru persoanele vizate este scăzut. În cazuri de risc ridicat, se notifică și persoanele afectate, iar incidentul trebuie documentat în scris. Nerespectarea acestor termene poate atrage amenzi de până la 10 milioane de euro sau 2% din cifra de afaceri globale.

Direciva NIS2, transpusă în dreptul românesc prin OUG 155/2024, viză în principal firmele medii și mari din sectoare critice precum energia, sănătatea sau sectorul financiar. Deși anumite categorii sunt acoperite indiferent de mărime, un magazin online mic nu intră, de regulă, în sfera de aplicare directă a NIS2. Totuși, GDPR se aplică oricui prelucrează date personale. Mai mult, conform Legii 58/2023, menționată de DNSC, responsabilitatea securității sistemului revine celui care îl deține, administrează sau utilizează.

Acțiuni imediate: ce să ceri firmei de hosting

Dacă site-ul este găzduit la un furnizor extern, primirea este să contactezi imediat acea firmă. Pe un hosting partajat sau administrat, actualizarea e de regulă sarcina furnizorului. De exemplu, Hostico a anunțat aplicarea remedierii pe toate mediile de găzduire, în timp ce cyber_Folks a confirmat repararea tuturor versiunilor PHP din infrastructura sa, cu mențiunea că la VPS-urile neadministrate responsabilitatea revine clientului.

Ce trebuie să ceri concret: 1. Confirmare scrisă a versiunii: Solicită un răspuns documentat care să specifice exact ce versiune de PHP rulează pe serverul tău. Pentru seria 8.5, minimul necesar este 8.5.12; pentru 8.4, cel puțin 8.4.27; pentru 8.3, cel puțin 8.3.36; pentru 8.2, cel puțin 8.2.35. Dacă versiunea e mai veche, întreabă dacă remedierea este inclusă, deoarece unii furnizori aplică patch-uri fără a schimba numărul de versiune. 2. Confirmarea repornirii proceselor: Cere dovada că procesele PHP au fost repornite după actualizare, altfel codul vechi poate rămâne activ în memorie. 3.

Verificarea jurnalelor: Solicită acces la jurnalele de server începând din 20 octombrie, ora 18:00, pentru a identifica eventualele semne de acces neautorizat. Poți verifica singur în panoul de administrare dacă au apărut conturi de administrator nedorite. 4. Copie de rezervă: Cere o copie completă a site-ului, a bazei de date și a jurnalelor.

În caz de incident, aceste fișiere servesc ca dovezi pentru autoritățile de cercetare sau pentru asigurarea. 5. Întrebarea despre a treia breșă: Pe 23 octombrie, echipa PHP a anunțat o a treia vulnerabilitate (CVE-2026-115560). Aceasta afectează doar configurații neobișnuite și nu are încă o reparație oficială. Măsura temporară sugerată este dezactivarea parametrului `session. upload_progress. enabled` și repornirea proceselor. Întreabă furnizorul dacă a aplicat această măsură.

Ce să ceri dezvoltatorului și administratorului

Cei care au dezvoltat site-ul trebuie întrebați despre necesitatea migrării de pe versiunile vechi. PHP 8.1 și versiunile anterioare nu mai primesc reparații oficiale. Deși unii furnizori oferă patch-uri temporare pentru ele, CISA recomanda, pentru instituțiile americane, scoaterea de pe internet a sistemelor care nu pot fi actualizate.

De asemenea, orice modificare pe server trebuie făcută în colaborare cu firma de hosting. Dacă suspectezi că datele clienților au fost afectate, este recomandat să consulți un specialist în securitate sau un avocat înainte de a trimite notificarea oficială. Termenul de 72 de ore pentru GDPR curge de la momentul în care ai o certitudine rezonabilă a incidentului.

Pentru viitorul imediat, pune în calendar migrarea de pe PHP 8.2, care nu mai primește actualizări de securitate după 31 decembrie 2026. Documentează fiecare pas: data, ora și rezultatul fiecărei verificări. Alerta oficială în limba română este disponibilă pe dnsc. ro.

Surse: php. net, CISA, DNSC, Centrul canadian pentru securitate cibernetică, Palo Alto Networks (Unit 42), watchTowr, W3 Techs, IBM, Wall-Street. ro, Hostico, cyber_Folks, Regulamentul GDPR, OUG 155/2024, Legea 58/2023.