php2shell: cum am protejat serverele GigasHost în noaptea de 21 spre 22 octombrie

„Am citit în știri despre o vulnerabilitate gravă în PHP. Site-ul meu e afectat?” E întrebarea firească pe care și-o pune acum orice proprietar de site. Răspunsul scurt, pentru clienții GigasHost: nu mai e. Toate serverele pe care le administrăm au primit reparațiile în noaptea de 21 spre 22 octombrie, înainte de începutul programului de lucru.

Răspunsul lung e articolul de față. Îl scriem din două motive. Primul: vrem să știi exact ce s-a întâmplat și ce am făcut, nu doar să-ți spunem că „totul e în regulă”. Al doilea: dacă ai site-uri și la alți furnizori sau un server pe care îl administrezi singur, vrei să știi ce trebuie verificat acolo.

Ce este php2shell, fără jargon

Pe 21 octombrie 2026, echipa care dezvoltă limbajul PHP a publicat, în regim de urgență, patru versiuni noi: 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Toate închid aceleași două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, notate amândouă cu 9.2 din 10 pe scala CVSS v4.0. Pentru că permit unui atacator să ajungă de la o simplă cerere web la controlul serverului, au primit repede porecla „php2shell”.

Ca să înțelegi de ce e o problemă de găzduire și nu doar una de site, gândește-te la o mașină. WordPress, temele și pluginurile sunt caroseria, interiorul și accesoriile: lucrurile pe care le vezi și le alegi tu. PHP e motorul. Poți avea cea mai bună caroserie din lume; dacă motorul are un defect de fabricație, mașina nu e sigură. Iar motorul nu-l schimbă proprietarul, ci service-ul.

Pe scurt, despre cele două defecte:

• Prima vulnerabilitate apare când PHP rămâne fără memorie exact în timp ce pregătește o cerere. Procesul se poate opri cu datele interne pe jumătate construite, iar etapa de curățenie le folosește ca și cum ar fi valide. Un atacator care provoacă intenționat situația asta poate ajunge să ruleze cod.
• A doua vulnerabilitate ține de ce „rămâne în urmă” între două cereri. O parte din starea internă a unei cereri poate rămâne agățată chiar și după ce memoria ei a fost deja eliberată, iar cererea următoare, procesată de același proces PHP, o poate folosi. O cerere rău intenționată poate astfel pregăti terenul pentru următoarea.

Echipa PHP spune clar că e expusă orice instalare care servește pagini web, indiferent de modul în care rulează PHP pe server. Anunțul complet e pe php.net.

De ce o vulnerabilitate în PHP e responsabilitatea furnizorului de găzduire

Majoritatea problemelor de securitate pe care le vedem zilnic sunt la nivelul site-ului: un plugin neactualizat, o parolă slabă, o temă descărcată de pe un site dubios. Pe acelea le poate repara, cel puțin teoretic, oricine are acces la panoul WordPress.

php2shell e altfel. Atacul se petrece în PHP, înainte ca site-ul propriu-zis să apuce să ruleze. Asta înseamnă că:

• Proprietarul site-ului nu poate face nimic din panoul de administrare. Nu există un plugin care să repare PHP-ul și nici o setare WordPress care să închidă breșa.
• Pe găzduirea partajată, nici măcar nu ai acces la PHP. Versiunea de PHP, pachetele și configurația serverului sunt în grija furnizorului.
• Toate site-urile de pe server sunt în aceeași situație, indiferent cât de bine sunt întreținute individual.

De aceea, într-o situație ca asta, întrebarea relevantă nu e „ce fac eu?”, ci „ce face furnizorul meu și cât de repede?”.

Cronologia: de ce viteza a contat atât de mult

Ce a făcut php2shell deosebit de periculos n-a fost doar gravitatea, ci și ordinea evenimentelor.

Marți, 20 octombrie. Echipa PHP anunță o lansare de securitate critică pentru a doua zi, la ora 17:00 (ora României). Detaliile vulnerabilităților încep să circule public înainte ca reparația să fie disponibilă.

Miercuri, 21 octombrie, dimineața. Sunt raportate primele atacuri reale. Exploit-ul era deja folosit înainte ca reparația să existe.

Miercuri, în jur de 16:35. PHP publică versiunile reparate, puțin înainte de ora anunțată. Pentru versiunile 7.4, 8.0 și 8.1, ieșite din suportul oficial, echipa oferă totuși patch-uri minimale, semn al gravității situației.

Miercuri seara și noaptea. Furnizorii de panouri și de sisteme de operare pentru servere, precum cPanel și CloudLinux, își publică pachetele reparate, treptat, versiune cu versiune.

Joi, 22 octombrie, înainte de ora 6:30. Toată infrastructura GigasHost rulează pe pachete reparate.

Când un exploit circulă înaintea patch-ului, fiecare oră dintre publicarea reparației și instalarea ei e o oră în care serverul e expus unui atac deja cunoscut. Exact asta e diferența dintre un furnizor care urmărește activ anunțurile de securitate și unul care aplică actualizările „la următoarea fereastră de mentenanță”.

Ce am făcut, concret, pe serverele noastre

Infrastructura noastră folosește cPanel și CloudLinux, servește site-urile prin LiteSpeed și ține fiecare cont separat de celelalte cu CageFS. Pe fiecare server coexistă mai multe versiuni de PHP, pentru că unele aplicații mai vechi nu pot rula pe cele mai noi. Asta face o actualizare de urgență mai complexă decât pare: nu repari „PHP-ul”, ci fiecare versiune de PHP în parte.

1. Am închis calea de atac cunoscută, până la patch

Prima măsură, aplicată pe toate versiunile de PHP de pe toate serverele, a fost recomandarea temporară a echipei PHP: dezactivarea funcției session.upload_progress. Pe scurt, e un mecanism prin care PHP notează în sesiune progresul unui fișier încărcat, înainte să ruleze orice cod al site-ului. Exploit-ul public îl folosea ca punct de intrare.

Am aplicat setarea la nivel de server, nu în setările fiecărui site, pentru că acolo nu poate fi anulată de o aplicație sau de un fișier de configurare din cont. Pentru site-uri nu se schimbă nimic vizibil: barele de progres moderne la încărcarea fișierelor se calculează în browser.

2. Am instalat pachetele reparate, pe toate versiunile

Am actualizat apoi fiecare versiune de PHP de pe fiecare server, inclusiv versiunile mai vechi pe care rulează încă unele aplicații. Pe unele servere, actualizarea a însemnat sute de pachete.

3. Am verificat reparația în pachete, nu după numărul versiunii

Un detaliu pe care puțini îl știu: multe pachete reparate nu schimbă numărul de versiune afișat. Reparația e adusă în codul existent și consemnată în jurnalul de modificări al pachetului. Un PHP afișat drept 8.3.35 poate fi perfect reparat, deși 8.3.36 e versiunea oficială cu fix.

De aceea n-am considerat un server rezolvat după numărul de versiune, ci după jurnalul de modificări al fiecărui pachet instalat. Fiecare versiune de PHP a fost bifată individual.

4. Am reîmprospătat izolarea conturilor și am repornit procesele PHP

Pe serverele noastre, fiecare cont rulează izolat, într-un mediu propriu care are copia lui pentru anumite componente de sistem. După o actualizare de PHP, mediile izolate trebuie reîmprospătate, iar procesele PHP pornite înainte de actualizare trebuie oprite. Altfel, în memorie poate rula în continuare codul vechi, vulnerabil, chiar dacă pe disc pachetul e deja nou. Pasul ăsta face parte din procedura noastră după orice actualizare de PHP.

5. Am făcut curățenie în versiunile vechi

Am folosit ocazia și pentru un inventar: ce versiuni de PHP există pe fiecare server și câte site-uri le folosesc efectiv. Versiunile foarte vechi, pe care nu le mai folosea niciun site și pentru care nu exista reparație, au fost dezactivate. O versiune pe care nimeni nu o mai poate selecta e o versiune care nu mai poate fi exploatată.

Unde intervine WAF-ul și unde nu

Dacă ai un plan de găzduire cu WAF, te poți întreba, pe bună dreptate: „Nu tocmai de asta am firewall?”. Răspunsul cinstit are două părți.

Ce poate face un WAF într-o situație ca asta. Un firewall aplicativ inspectează cererile înainte să ajungă la site și poate bloca tiparele de atac cunoscute. Când un exploit e public, regulile noi care îl recunosc sunt un strat de protecție valoros în orele dintre anunț și instalarea patch-ului. Asta se numește „virtual patching”: nu repari defectul, dar oprești forma cunoscută a atacului.

Ce nu poate face. Un WAF nu repară PHP-ul. Recunoaște forme de atac, iar atacatorii schimbă forma. Echipa PHP însăși avertizează că măsurile temporare blochează căile de atac confirmate, dar nu și variantele lor. În plus, eficiența regulilor de firewall depinde de combinația concretă de server web și motor de reguli. Același set de reguli poate bloca un atac pe un tip de server și doar îl poate semnala pe altul.

De aceea, în noaptea de 21 spre 22 octombrie, WAF-ul a fost un strat de protecție, nu soluția. Soluția a fost patch-ul, instalat cât mai repede posibil. Am explicat pe larg această logică a straturilor în ghidul nostru despre găzduirea cu WAF. php2shell e un exemplu din manual: securitatea nu stă într-un singur produs, ci în mai multe straturi și într-o echipă care reacționează repede.

O schimbare de comportament pe care e bine s-o cunoști

Reparația pentru prima vulnerabilitate schimbă felul în care PHP tratează lipsa de memorie, conform jurnalelor de modificări ale pachetelor. Până acum, un script care trecea peste limita de memorie se încheia cu un mesaj de eroare. Acum PHP nu mai încearcă să-l termine frumos, ci oprește complet procesul.

Pentru un site sănătos asta nu schimbă nimic. Pentru o aplicație care trecea „la limită”, de exemplu un import mare de produse într-un magazin online sau un raport generat dintr-o bază de date mare, se poate traduce printr-o pagină de eroare goală în loc de mesajul obișnuit. Dacă observi așa ceva după 22 octombrie, deschide un tichet și verificăm împreună dacă e vorba de limita de memorie.

Dacă ai site-uri și la alți furnizori: ce să verifici

Mulți clienți au site-uri în mai multe locuri: un site vechi rămas la un alt furnizor, un magazin pe un server administrat de altcineva, un proiect personal pe un VPS. Pentru fiecare, merită să ceri un răspuns la aceste cinci întrebări:

1. Au fost instalate pachetele PHP care repară CVE-2026-109618 și CVE-2026-109619? Un răspuns concret conține date și versiuni, nu doar „suntem în siguranță”.
2. Pe toate versiunile de PHP de pe server? Site-ul tău poate rula pe altă versiune decât cea implicită a serverului.
3. Cum s-a verificat reparația? Ideal, în jurnalul de modificări al pachetelor sau prin numerele oficiale de versiune.
4. Au fost repornite procesele PHP? Un pachet nou pe disc nu ajută dacă procesele vechi rulează încă în memorie.
5. Ce versiune de PHP folosește site-ul meu și mai primește reparații? PHP 8.1 și versiunile mai vechi nu mai primesc oficial actualizări, iar PHP 8.2 primește reparații de securitate doar până la 31 decembrie 2026.

Dacă un furnizor nu-ți poate răspunde concret la aceste întrebări în 24–48 de ore după un anunț de gravitatea asta, ai aflat ceva important despre cum își tratează securitatea.

Dacă ai un VPS sau un server dedicat

Pe un server propriu, nimeni nu instalează patch-ul în locul tău, cu excepția cazului în care serverul e administrat de cineva. Ai nevoie, pe scurt, de actualizarea tuturor versiunilor de PHP instalate, de repornirea tuturor proceselor PHP, de reîmprospătarea mediilor izolate, acolo unde există, și de un control al fiecărui site odată ce actualizarea s-a terminat.

Pentru clienții cu servere dedicate, VPS-uri sau servere semidedicate administrate de GigasHost, toate acestea au fost făcute de echipa noastră, ca parte a administrării incluse.

Întrebări frecvente

Sunt client GigasHost. Trebuie să fac ceva?
Nu. Serverele au fost actualizate și verificate. Dacă ai observat erori neobișnuite pe site după 22 octombrie, scrie-ne și verificăm.

Site-ul meu nu e WordPress. Mă privește?
Da, dacă e scris în PHP. php2shell e o problemă a limbajului PHP, nu a WordPress-ului. Sunt expuse la fel magazine pe alte platforme, aplicații făcute la comandă sau formulare vechi.

Un plugin de securitate m-ar fi protejat?
Nu. Un plugin de securitate rulează în interiorul aplicației, iar atacul are loc înainte ca aplicația să pornească.

Cum văd ce versiune de PHP are site-ul meu?
În WordPress, din Unelte → Sănătatea site-ului → Informații → Server. Pentru clienții noștri, versiunea se vede și se poate schimba din cPanel. Reține însă că numărul afișat nu spune singur dacă versiunea e reparată.

Ar trebui să schimb versiunea de PHP?
Pentru php2shell, nu. Toate versiunile folosite de site-urile clienților noștri au primit reparația. Dacă site-ul tău rulează pe o versiune mai veche de 8.2, e totuși un moment bun să discutăm o migrare către o versiune încă întreținută.

Concluzie

php2shell a fost genul de incident pentru care există, de fapt, un furnizor de găzduire administrată: o problemă pe care proprietarul site-ului nu o poate rezolva singur, un exploit care circula înaintea reparației și o fereastră de expunere măsurată în ore. Pentru clienții GigasHost, fereastra s-a închis în aceeași noapte.

Dacă vrei ca data viitoare site-ul tău să fie pe un server unde cineva urmărește anunțurile de securitate și acționează imediat, uită-te la planurile noastre: Basic WAF Platform, Business WAF Platform și Ecommerce WAF Platform, cu SLA de remediere de la 6 ore la 1 oră și migrare gratuită, fără întreruperi. Iar dacă ai întrebări despre site-ul tău actual, oriunde ar fi găzduit, scrie-ne. Îți spunem sincer ce vedem.