Pe 21 octombrie 2026, proiectul PHP a publicat corecția pentru două vulnerabilități critice care permit unui atacator să ruleze cod pe server fără nicio parolă. Cinci zile mai târziu, agenția americană de securitate cibernetică (CISA) le-a trecut pe lista vulnerabilităților exploatate deja în atacuri reale și a dat instituțiilor federale trei zile ca să actualizeze. Dacă în contractul tău de mentenanță scrie „actualizări lunare”, site-ul a stat descoperit tot intervalul acesta. Am arătat ce se strică la un site când nu se uită nimeni; aici e vorba de un singur rând din contract: termenul în care se aplică o actualizare de securitate.
Răspunsul scurt: pentru o vulnerabilitate exploatată activ, termenul pe care îl soliciți în scris e de cel mult 72 de ore de la publicarea corecției, cu confirmare scrisă după fiecare intervenție. Ciclul lunar rămâne bun pentru restul actualizărilor.
Ce s-a întâmplat cu PHP2Shell, zi cu zi
Cercetătorii au numit cele două vulnerabilități PHP2Shell. Ele privesc PHP, limbajul pe care rulează WordPress și, odată cu el, cele mai multe site-uri de prezentare și magazine online. La 4 noiembrie 2026, după W3Techs, PHP rula pe 69,1% dintre site-urile al căror limbaj de server se poate identifica. Asta înseamnă că o vulnerabilitate în PHP nu lovește o nișă, ci aproape șapte site-uri din zece.
Cronologia, din sursele primare:
- 20 octombrie: proiectul PHP anunță două vulnerabilități cu scorul 9,2 din 10, deci în treapta critică, și pregătește corecția.
- 21 octombrie: apar versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Anunțul oficial spune că nu există o protecție completă în afară de actualizare.
- 26 octombrie: CISA adaugă ambele vulnerabilități în catalogul celor exploatate activ.
- 29 octombrie: expiră termenul dat de CISA instituțiilor federale americane, adică trei zile de la intrarea în catalog.
Cât de repede au reacționat cei care administrează servere? Qualys, o firmă care scanează infrastructura clienților ei, a numărat 156 de milioane de instalări PHP cu versiune cunoscută. În primele 12 ore după corecție fuseseră actualizate 199.000, iar în primele 24 de ore, 581.000, adică 0,37%. Deci, la o zi după publicare, peste 99 din 100 de instalări rulau încă versiunea vulnerabilă.
Cifra care contează cel mai mult pentru un patron vine tot de la Qualys: 71% dintre instalările numărate rulau versiuni între PHP 5.4 și 8.1, pe care proiectul PHP nu le mai actualizează. Pentru ele, corecția oficială nu există. Unele distribuții de Linux au adus corecții separate, dar asta depinde de cine administrează serverul.
De ce „actualizări lunare” nu mai acoperă riscul
Ia o firmă de transport frigorific din Oradea, Frigotrans Vest, cu un site de prezentare și un formular de cerere de ofertă. Contractul de mentenanță spune „actualizări lunare”, iar furnizorul le face pe 15 ale lunii. Corecția PHP a apărut pe 21 octombrie, deci următorul ciclu cădea pe 15 noiembrie. Asta înseamnă 25 de zile de la corecție și 17 zile după termenul pe care CISA l-a considerat suficient pentru instituțiile federale.
Nimeni nu a încălcat contractul. Furnizorul a făcut exact ce scria acolo.
Problema e că ritmul lunar a fost gândit pentru o lume în care trecea mult timp între publicarea unei vulnerabilități și primul atac. Cazul PHP2Shell arată altă ordine de mărime: atacurile au fost confirmate la cinci zile după corecție. Un ciclu fix de 30 de zile lasă, în medie, cam două săptămâni de expunere pentru fiecare vulnerabilitate critică, iar firma nu are cum să vadă asta din afară.
Mai e o capcană, care ține de cine răspunde de ce. Versiunea de PHP stă pe server, deci o actualizează gazda. Nucleul WordPress, tema și pluginurile stau în site, deci le actualizează cine face mentenanța. Dacă cele două roluri aparțin unor firme diferite, PHP2Shell cade exact între ele: gazda așteaptă o solicitare, iar furnizorul de mentenanță presupune că de server răspunde gazda. Frecvența actualizărilor nu e un semn de instabilitate, cum circulă un mit vechi pe care l-am discutat la miturile despre securitatea WordPress, dar ea contează doar dacă cineva are sarcina scrisă să le aplice.
Ce termen soliciți, pe trepte de gravitate
Un singur termen pentru toate actualizările ar fi ori prea lent pentru cele grave, ori prea scump pentru cele mărunte. Soluția practică e un tabel cu trepte, pus în anexa contractului. Valorile de mai jos sunt cele pe care le-am trece noi; termenul de 72 de ore urmează logica celor trei zile date de CISA.
| Situația | Termenul solicitat | Dovada pe care o primești |
|---|---|---|
| Vulnerabilitate trecută în catalogul CISA al celor exploatate activ, pe o componentă folosită de site | cel mult 72 de ore de la publicarea corecției | e-mail cu versiunea instalată și ora aplicării |
| Vulnerabilitate critică, fără atacuri confirmate | cel mult 7 zile | mențiune în raportul lunar, cu data |
| Actualizări obișnuite de nucleu, temă și pluginuri | ciclul lunar sau săptămânal din contract | raportul lunar |
| Versiune de PHP care iese din suport | plan de trecere, cu dată, înainte de sfârșitul suportului | data scrisă în contract sau în raport |
Ultimul rând are deja un termen concret: proiectul PHP anunță sfârșitul suportului pentru PHP 8.2 pe 31 decembrie 2026. Un site care rulează azi pe 8.2 are nevoie de trecerea la o versiune nouă până atunci, altfel la următoarea vulnerabilitate gravă intră în categoria celor 71% fără corecție oficială.
Termenul scurt are un cost, iar furnizorul îl va pune în ofertă. Liniile de cost ale unei mentenanțe serioase le-am desfăcut separat, în cât costă mentenanța unui site și ce cuprinde. Diferența de preț dintre un ciclu lunar și unul cu treaptă de 72 de ore se compară cu costul refacerii unui site compromis, la care se adaugă zilele în care formularul nu primește nicio cerere.
Ce verifici și ce soliciți, de mâine
Trimite gazdei o întrebare la care se răspunde cu un număr
Scrie un e-mail furnizorului de găzduire cu două întrebări: ce versiune exactă de PHP rulează site-ul tău și la ce dată a fost aplicată corecția pentru vulnerabilitățile din octombrie 2026 (CVE-2026-109618 și CVE-2026-109619). Răspunsul bun conține un număr de versiune egal sau mai mare decât 8.2.35, 8.3.36, 8.4.27 sau 8.5.12, după ramura folosită. Dacă serverul rulează o versiune mai veche cu corecție adusă de distribuția de Linux, răspunsul trebuie să numească avizul distribuției: Qualys avertizează că aceste corecții păstrează uneori numărul vechi de versiune, deci numărul singur poate înșela.
Un răspuns de tipul „serverele noastre sunt actualizate”, fără număr și fără dată, înseamnă că întrebarea a rămas fără răspuns. Trimite-o din nou.
Rescrie clauza de actualizări pe trepte și solicită confirmare după fiecare intervenție critică
Ia tabelul de mai sus și solicită-l ca anexă la contractul de mentenanță, cu cifrele scrise: ore și zile, nu „în cel mai scurt timp”. Adaugă obligația ca, după fiecare actualizare din prima treaptă, furnizorul să îți trimită un e-mail cu componenta, versiunea și ora. Semnul că ai terminat: în contractul semnat apar cifre lângă fiecare treaptă, iar la următoarea vulnerabilitate critică primești e-mailul fără să îl soliciți.
Află dacă firma ta intră sub NIS2
Directiva NIS2, transpusă în România prin OUG 155/2024, se aplică entităților esențiale și importante din sectoarele enumerate de lege, înregistrate la Directoratul Național de Securitate Cibernetică (DNSC). Pentru ele, gestionarea vulnerabilităților e obligație legală (articolul 21 din directivă), iar un incident semnificativ se semnalează cu o avertizare timpurie în cel mult 24 de ore de la momentul în care firma află de el (articolul 23). Întreabă persoana care răspunde de conformitate dacă firma s-a înregistrat la DNSC. Dacă răspunsul e da, contractul cu furnizorul de mentenanță trebuie să spună în câte ore te anunță el de un incident, altfel termenul de 24 de ore începe să curgă fără ca tu să știi.
Ce nu rezolvă un termen scurt
Viteza fără o copie de siguranță proaspătă mută riscul în altă parte: o actualizare de PHP aplicată în grabă poate opri un plugin vechi și scoate formularul de ofertă din funcțiune. Termenul de 72 de ore presupune deci o copie făcută chiar înaintea intervenției și cineva care știe să o restaureze.
Niciun contract, oricât de bun, nu acoperă un site care rulează pe o versiune de PHP fără suport. Acolo nu există corecție de aplicat, oricât de scurt ar fi termenul, iar singura măsură reală e trecerea la o versiune actualizată. Iar dacă firma are și alte servere expuse la internet, de pildă un sistem de facturare sau un VPN pentru birou, clauza din contractul site-ului nu le atinge: fiecare are nevoie de propriul responsabil și de propriul termen.
Cum te poate ajuta Emblematic
Pachetul „Găzduire și mentenanță web” pune găzduirea și mentenanța tehnică în aceeași mână: actualizările de WordPress, de temă și de pluginuri, verificările de securitate și monitorizarea. Așa, versiunea de PHP de pe server și actualizările din site au același responsabil, iar o vulnerabilitate ca PHP2Shell nu mai cade între două firme.
Dacă vrei să știi ce termen de actualizare ar trebui să scrie în contractul site-ului tău, scrie-ne. Îți trimitem clauza pe trepte de gravitate, completată pentru site-ul tău, și întrebările exacte pe care le trimiți gazdei.
