Două vulnerabilități critice în PHP: actualizări de urgență azi, la ora 17:00

Dacă firma ta are un site, un magazin online, un CRM sau o aplicație web internă, cel mai probabil rulează pe PHP. Limbajul stă în spatele majorității site-urilor de pe internet, inclusiv al celor create pe WordPress, Magento sau PrestaShop și găzduite pe servere cu cPanel. Tocmai de aceea, anunțul făcut de echipa PHP nu este unul obișnuit: astăzi, miercuri 21 octombrie, la ora 17:00 (ora României), apar actualizări de urgență pentru două vulnerabilități critice. La Activ.NET tratăm astfel de anunțuri ca pe o alarmă reală: când se publică detaliile, atacatorii au la dispoziție aceleași informații ca administratorii de sistem.

#Ce s-a întâmplat

Pe 20 octombrie 2026, echipa de securitate PHP a publicat pe php.net un avertisment neobișnuit, emis înainte de lansarea corecturilor. Pe scurt:

• actualizarea de securitate este programată pentru miercuri, 21 octombrie 2026, la 14:00 UTC (17:00, ora României);
• rezolvă două vulnerabilități critice, ambele evaluate cu scorul 9,2 din 10 (CVSS v4.0);
• toți administratorii și utilizatorii de PHP sunt îndemnați „să se pregătească acum”, ca să poată face actualizarea imediat ce apar noile versiuni;
• echipa PHP își rezervă dreptul de a publica pachetele mai devreme dacă detaliile devin publice sau dacă apar dovezi de atacuri active;
• versiunile afectate și cele corectate vor fi anunțate oficial abia la momentul lansării.

Potrivit companiei de securitate watchTowr, citată de BleepingComputer, ambele probleme permit executarea de cod de la distanță (RCE), ceea ce înseamnă că un atacator ar putea rula propriile comenzi direct pe server. Tot watchTowr susține că vulnerabilitățile afectează mai multe generații de PHP, de la versiunea 5 până la 8, că a reprodus deja una dintre ele și că, până în acest moment, nu a detectat exploatări în mediul real. Aceste informații nu au fost încă confirmate oficial de echipa PHP, care amână detaliile până la publicarea patch-urilor.

Un indiciu clar privind gravitatea situației este faptul că detaliile despre vulnerabilități trebuiau să rămână sub embargo până joi, dar au apărut prematur pe internet (printr-o postare ștearsă ulterior pe Hacker News), grăbind astfel calendarul publicării.

#Impact pentru firme

O vulnerabilitate de tip RCE în PHP este una dintre cele mai grave probleme posibile pentru un site. Dacă este exploatată, atacatorul poate:

• să modifice sau să șteargă complet site-ul și baza de date;
• să extragă datele confidențiale ale clienților (conturi, date de contact, comenzi), cu toate consecințele legate de GDPR;
• să instaleze scripturi malițioase care trimit spam, minează criptomonede sau lansează atacuri asupra altor sisteme;
• să folosească serverul compromis ca punct de plecare pentru a pătrunde mai adânc în rețeaua internă a companiei.

Cel mai ridicat risc îl au site-urile care funcționează pe versiuni vechi de PHP, scoase de mult din suport și care nu mai primesc corecții de securitate. Încă există numeroase site-uri de prezentare sau aplicații interne lăsate pe PHP 7.x sau chiar 5.x doar pe principiul „dacă merge, nu ne atingem de el”. Dacă vulnerabilitățile afectează și aceste versiuni vechi, pentru ele nu va exista nicio remediere oficială. Singura protecție reală rămâne migrarea către o versiune cu suport activ.

#Recomandări concrete

1. Află chiar acum ce versiune de PHP folosește site-ul tău. În cPanel o poți verifica în secțiunea Software → MultiPHP Manager (sau Select PHP Version). Dacă site-ul e administrat de o agenție sau de un programator, întreabă-i ce versiune rulează și când aplică actualizarea.
2. Fă un backup complet înainte de ora 17:00. Salvează atât fișierele, cât și baza de date în altă locație decât serverul pe care rulează site-ul. Dacă procedura de actualizare provoacă erori sau dacă serverul a fost deja accesat neautorizat, backup-ul este planul de rezervă esențial.
3. Actualizează imediat după lansare. Pe serverele administrate cu cPanel, versiunile noi devin disponibile prin pachetele EasyApache; pe serverele Linux standard, pachetele se actualizează cu managerul de pachete (apt sau dnf), imediat ce distribuția publică versiunile corectate.
4. Planifică migrarea de pe versiunile fără suport. Dacă proiectul tău rulează încă pe PHP 7.x sau pe o ramură mai veche, trecerea la PHP 8.x nu mai poate fi amânată. Testează migrarea întâi pe un mediu de test (staging), deoarece modulele, temele sau librăriile vechi pot fi incompatibile.
5. Urmărește jurnalele (logurile) serverului în zilele următoare. Cererile suspecte către site, fișierele .php apărute în directoarele de încărcare (upload) sau vârfurile nejustificate de trafic indică adesea scanări automate ori tentative de compromitere. La Activ.NET urmărim aceste semnale pe serverele pe care le administrăm prin serviciul de administrare servere.

#Concluziile noastre

Un avertisment dat din timp de echipa PHP este un gest rar și trebuie luat în serios. Vestea bună e că administratorii au câteva ore să se pregătească. Cea mai riscantă decizie ar fi amânarea, pe motiv că „să vedem dacă e chiar așa grav”: după publicarea corecturilor, atacatorii le pot analiza ca să afle exact unde e problema, iar atacurile automate apar de obicei în câteva zile, uneori chiar în câteva ore. Dacă nu știi cu exactitate ce versiune de PHP rulează pe infrastructura ta sau nu ai o persoană dedicată mentenanței, echipa Activ.NET te poate ajuta cu verificarea și cu găzduire web întreținută la zi.

Inspirat din: BleepingComputer, PHP.net