Vulnerabilitatea PHP din 21 octombrie: ce s-a întâmplat și care este situația în prezent

Miercuri, 21 octombrie, au fost făcute publice două vulnerabilități grave de securitate în PHP, limbajul de programare pe care rulează marea majoritate a site-urilor web, inclusiv WordPress. Este posibil să fi observat ceva, deoarece o parte a zilei site-urile găzduite la noi au fost offline. În acest articol prezentăm ce s-a întâmplat, cum am acționat și care este situația acum.

Ce s-a întâmplat?

Vulnerabilitățile (CVE-2026-109618 și CVE-2026-109619) permiteau persoanelor neautorizate să execute cod pe un server web. Acesta este practic cel mai grav tip de vulnerabilitate care există: un atacator nu are nevoie de o parolă pentru aceasta, iar vulnerabilitatea afectează aproape întregul internet.

Cum am acționat

1. Măsură temporarămiercuri, 21 octombrie, 10:00

   La acel moment se știa doar că existau două vulnerabilități grave în toate versiunile de PHP, cu un scor CVE de 9,2. Detaliile nu erau încă disponibile și nu se cunoșteau încă hack-uri reușite, deși, de exemplu, Cloudflare observa deja tot mai multe încercări. Deoarece detaliile vulnerabilității nu erau cunoscute, nimeni nu știa exact despre ce era vorba și ce se putea face pentru a limita riscul. Au apărut totuși tot mai multe măsuri de atenuare și acțiuni posibile pentru limitarea riscului. Pe acestea le-am implementat imediat, cum ar fi dezactivarea anumitor funcții PHP și actualizarea firewall-ului de mai multe ori.
   Începând cu ora 10:00, am rulat de asemenea continuu scanări antimalware foarte stricte, astfel încât să observăm imediat dacă un script era plasat undeva pe serverele noastre sau în conturile clienților noștri. Acest lucru nu s-a întâmplat.

2. Site-uri offlinemiercuri, 21 octombrie, 15:15

   Deși nu am observat încercări de exploatare pe serverele noastre, am decis să optăm pentru cea mai sigură variantă: totul offline. Principalul motiv a fost că aveam îndoieli cu privire la eficiența măsurilor de atenuare (soluțiilor temporare) care circulau pe internet, deoarece nimeni nu putea confirma că acestea ar oferi o protecție suficientă.
   Într-o situație cu atât de multe incertitudini și cu posibile consecințe enorme, câteva ore de nefuncționare pot fi justificate; asumarea riscului nu.

3. Soluție oficialămiercuri, 21 octombrie, 16:00

   Dezvoltatorii PHP au publicat actualizarea oficială care conținea corecția pentru versiunile 8.3, 8.4 și 8.5. După aceea, a urmat așteptarea pachetelor actualizate de la CloudLinux, furnizorul versiunilor de PHP de pe serverele noastre.
   Odată cu publicarea actualizării au devenit cunoscute și detaliile vulnerabilităților, ceea ce ne-a confirmat presimțirea: măsurile de atenuare cunoscute și regulile suplimentare de firewall reduceau, într-adevăr, riscul unui atac, însă acest lucru nu era suficient pentru a proteja serverul.

4. Soluție temporarămiercuri, 21 octombrie, 19:00

   Din păcate, a durat considerabil mai mult decât speram și ne așteptam până când CloudLinux a avut actualizările pregătite. Din contactul nostru cu alți furnizori a reieșit că nu eram singurii surprinși de această situație. Deoarece am observat că aceștia nu își respectaseră deja de mai multe ori termenele limită autoimpuse, am lucrat la o soluție temporară.
   Am instalat noi înșine versiunea PHP 8.3.36 pe toate serverele noastre și am trecut temporar toți clienții pe această versiune. 90% dintre site-uri au revenit online între orele 19:00 și 20:30. Singurele site-uri care nu au revenit online erau învechite și nu puteau funcționa cu o versiune modernă de PHP.

5. Actualizarejoi, 22 octombrie, 00:30

   Actualizările au devenit disponibile și am început imediat instalarea și verificarea acestora, server cu server.

6. Rezolvatjoi, 22 octombrie, 02:30

   Toate serverele au fost actualizate și toate site-urile au revenit online, pe versiunea de PHP pe care o foloseau anterior.

Înțelegem foarte bine că este neplăcut dacă site-ul dumneavoastră nu este accesibil o după-amiază și o seară întreagă. Totuși, acest inconvenient nu cântărește la fel de mult ca eventualele consecințe. Nu a fost niciodată necesar anterior să decidem să scoatem totul offline din precauție, însă dacă aceeași situație s-ar repeta, am proceda exact la fel.

Care este situația acum?

• Toate versiunile de PHP pe care le oferim, de la 5.2 până la 8.5 inclusiv, conțin corecțiile de securitate pentru ambele vulnerabilități.
• Cele câteva site-uri care rulau pe o versiune de PHP și mai veche, pentru care nu există o corecție, au fost mutate de noi pe o versiune corectată.
• Am verificat serverele, atât în timpul, cât și după apariția vulnerabilității, în căutarea unor urme de abuz, cum ar fi procese PHP blocate, procese suspecte, fișiere încărcate și cereri care corespund atacului cunoscut. Nu am găsit niciun indiciu că vulnerabilitatea a fost exploatată pe serverele noastre, iar înainte de a trece offline nu am găsit nicio încercare în acest sens.

Este site-ul meu separat de cele ale altor clienți?

Da. Fiecare pachet de hosting rulează la noi într-un mediu propriu, izolat. PHP rulează sub utilizatorul pachetului dumneavoastră, fără drepturi administrative pe server, și nu poate accesa fișierele sau bazele de date ale altor clienți. De asemenea, utilizarea procesorului și a memoriei este limitată per pachet. Mai multe detalii despre securitatea noastră nu sunt făcute publice în mod deliberat: cu cât un atacator știe mai puține lucruri, cu atât mai bine.