Când nu poți actualiza azi: un plan de atenuare în 48 de ore

Aplicație veche, furnizor care întârzie, echipament cu PHP inclus: ce decizii iei în primele 48 de ore după o vulnerabilitate critică, pe exemplul PHP2Shell.

Uneori, vestea despre o vulnerabilitate gravă vine într-un moment în care actualizarea nu se poate face pe loc. Aplicația e veche și nu suportă versiunea nouă. Furnizorul unui echipament promite fixul „în curând”. Firma care a construit site-ul nu mai răspunde la telefon. Așa a fost în octombrie 2026, cu vulnerabilitățile PHP2Shell: echipa PHP a publicat corecturile pe 21 octombrie, dar multe firme nu le puteau aplica în aceeași zi.

Articolul e pentru patronul sau managerul care se află în situația asta. Nu îți arată cum să configurezi un server. Îți arată ce decizii iei, în ce ordine și ce ceri echipei sau furnizorului în primele 48 de ore. Exemplul e PHP2Shell, dar pașii se aplică la orice vulnerabilitate critică.

Un lucru trebuie spus de la început: un plan de atenuare cumpără timp, nu rezolvă problema. Echipa PHP spune explicit că pentru PHP2Shell nu există o atenuare completă și că doar actualizarea e sigură. Tot ce urmează e o punte până la actualizare sau migrare, nu o alternativă.

Prima întrebare nu e „cum ne apărăm”, ci „unde rulează programul vulnerabil”. NCSC, agenția britanică de securitate cibernetică, pune inventarul pe primul loc. DNSC cere același lucru și amintește de locurile uitate: serverele de test, aplicațiile vechi folosite rar, soluțiile primite de la furnizori.

Pentru PHP2Shell, lista arată cam așa:

• site-ul de prezentare și magazinul online;
• aplicațiile interne (portal de clienți, intranet, formulare);
• copiile de test sau de dezvoltare uitate pe un server;
• echipamentele care au o interfață web cu PHP: unele NAS-uri, routere sau sisteme de administrare a clădirii. Echipa olandeză NCSC-NL ține o listă publică a produselor afectate.

Pentru fiecare sistem din listă notezi un nume: cine poate face o schimbare pe el azi. Poate fi colegul IT, hostingul, agenția care a făcut site-ul sau furnizorul echipamentului. DNSC recomandă desemnarea unui responsabil pentru fiecare instalare. Dacă un sistem nu are pe nimeni, ai aflat deja cea mai mare problemă.

Pe găzduire partajată sau administrată, PHP îl actualizează hostingul, nu tu. Scrie-le direct și întreabă trei lucruri: dacă au aplicat corecturile din 21 octombrie, când le aplică dacă nu și ce măsuri temporare au pus până atunci. Cere răspunsul în scris. La furnizorii de echipamente, întreabă când apare actualizarea și ce recomandă între timp.

FBI și NCSC spun același lucru: dacă actualizarea imediată nu e posibilă și nici măsurile temporare nu se pot aplica, sistemul se scoate offline până la remediere. Pentru un manager, decizia ține de două întrebări: cât costă o zi fără sistem și ce se pierde dacă sistemul e spart. Un site de prezentare poate fi înlocuit pentru câteva zile cu o pagină statică. Un magazin online sau un portal de clienți cere o discuție mai atentă, dar riscul unui server preluat include datele clienților.

Pentru PHP2Shell, echipa PHP a publicat câteva măsuri care reduc riscul. Le aplică cine administrează serverul, iar tu trebuie doar să știi ce să ceri:

• oprirea unei funcții PHP numite „session upload progress”, cu repornirea tuturor proceselor PHP;
• limite mai mici pentru dimensiunea cererilor primite și pentru numărul de câmpuri din ele;
• blocarea încărcărilor de fișiere acolo unde site-ul nu are nevoie de ele;
• setări de memorie impuse de administrator, pe care aplicația nu le mai poate modifica.

Cere confirmarea că măsurile au fost aplicate în configurația serverului, nu doar în aplicație, și că procesele PHP au fost repornite. DNSC precizează că fără repornire serverul poate rula în continuare cu setările vechi.

Un firewall de aplicație (WAF) filtrează cererile înainte să ajungă la server. Cloudflare a publicat reguli pentru PHP2Shell inclusiv în planul gratuit. DNSC pune însă o condiție clară: un WAF ajută doar dacă serverul nu poate fi accesat direct, ocolind filtrul. Cere echipei să confirme că serverul acceptă trafic doar prin WAF. Altfel, protecția e doar aparentă.

Tot ce nu e necesar azi e risc în plus: copiile de test, aplicațiile vechi care nu mai sunt folosite, formularele de încărcare a fișierelor la care nu se uită nimeni. Oprirea lor temporară e cea mai ieftină măsură din tot planul.

Dacă site-ul de prezentare trebuie scos offline, o pagină statică simplă, cu datele de contact și un mesaj scurt, ține firma vizibilă. Nu rulează PHP, deci nu e expusă la aceeași vulnerabilitate.

Atacurile pot începe înainte de patch. La PHP2Shell, prima tentativă raportată a fost pe 17 octombrie, cu patru zile înaintea anunțului. FBI recomandă urmărirea proceselor PHP care pornesc programe de linie de comandă sau descarcă fișiere. DNSC adaugă semnele de căutat începând cu 20 octombrie 2026, ora 15:00 UTC:

• fișiere noi sau modificate în directoarele site-ului;
• modificări în fișierele de configurare PHP din directoarele site-ului;
• sarcini programate sau chei de acces SSH noi;
• conturi noi de administrator în aplicație.

Dacă apare ceva, sistemul se izolează, jurnalele se păstrează, iar decizia nu mai e „când actualizăm”, ci „cum curățăm”.

Înainte de orice actualizare sau migrare, ai nevoie de un backup despre care știi că se poate restaura. „Avem backup” nu e același lucru cu „am restaurat ieri backup-ul pe o copie și a mers”. Cere a doua variantă și păstrează backup-ul separat de serverul afectat.

Planul de atenuare se încheie cu o dată. Dacă aplicația rulează pe o versiune PHP suportată, data e cea a actualizării. Dacă rulează pe PHP 8.1 sau mai vechi, pentru care proiectul PHP nu mai publică versiuni, data e cea a migrării, iar măsurile temporare rămân până atunci. Un plan fără dată devine, în practică, starea permanentă a sistemului.

DNSC atrage atenția asupra câtorva măsuri care dau senzația de siguranță, dar nu protejează împotriva PHP2Shell:

• pluginurile de securitate din WordPress sau din alte aplicații;
• modul de mentenanță al site-ului;
• dezactivarea încărcării de fișiere din setările aplicației;
• verificările de autentificare din aplicație.

Motivul e același pentru toate: ele intervin după ce PHP a procesat deja cererea. Vulnerabilitatea e înainte de ele.

1. Ora 0–4: inventarul, un responsabil pentru fiecare sistem, întrebările scrise către hosting și decizia online sau offline.
2. Ora 4–24: măsurile temporare oficiale, WAF doar cu serverul închis pentru accesul direct, oprirea a tot ce nu e necesar, pagina statică dacă e nevoie.
3. Ora 24–48: urmărirea semnelor de compromitere, backup restaurat de probă și o dată fixă pentru actualizare sau migrare.

La ME Digital ajutăm firmele care nu pot actualiza imediat: facem inventarul, aplicăm măsurile temporare, verificăm semnele de compromitere și pregătim actualizarea sau migrarea, ca parte din serviciile de securitate și actualizări. Dacă ai un sistem în situația asta, scrie-ne.

• PHP, anunțul de securitate din 21 octombrie 2026, cu măsurile temporare
• DNSC, Alertă: vulnerabilități critice în PHP (actualizată pe 22 octombrie 2026)
• NCSC (Marea Britanie), Critical security issue affecting PHP
• FBI Cyber Division, recomandările pentru vulnerabilitățile PHP (21 octombrie 2026)
• CERT-EU, Security Advisory 2026-018
• Cloudflare, protecția WAF pentru vulnerabilitățile PHP
• NCSC-NL, lista produselor care includ PHP
• The Hacker News, tentativa de exploatare din 17 octombrie raportată de Amazon