Dacă nu aveți de a face cu partea tehnică despre cum funcționează internetul, ieri a fost o zi obișnuită pentru dumneavoastră.
Pentru foarte mulți administratori de servere, furnizori de hosting, programatori și oameni care se ocupă de securitatea infrastructurii web, n-a fost.
Pe 21 octombrie au fost publicate de urgență actualizări pentru două vulnerabilități critice descoperite în PHP, tehnologia care stă în spatele unei părți uriașe din Internet. Cele două probleme, identificate drept CVE-2026-109618 și CVE-2026-109619 și grupate deja sub numele „PHP2Shell”, au primit un scor de severitate de 9,2 din 10.
Pe românește: foarte rău.
Dar ce este PHP și de ce ar trebui să ne intereseze?
Când deschideți un site, vedeți pagini, fotografii, formulare, produse, butoane. În spatele lor există însă programe care rulează pe server și care decid ce informații primiți, citesc baze de date, verifică autentificări, procesează comenzi și construiesc pagina pe care o vedeți.
PHP este una dintre tehnologiile care fac acest lucru.
WordPress, de exemplu, rulează pe PHP. La fel și numeroase alte platforme și aplicații web. Cercetătorii Wiz estimează că PHP se află, într-o formă sau alta, în spatele a aproximativ 70% dintre site-urile web.
Asta nu înseamnă că ieri „70% din Internet a fost spart”. Înseamnă că o tehnologie de care depinde o parte enormă a Internetului s-a dovedit vulnerabilă. Și nu vorbim despre o problemă într-un plugin obscur sau despre o parolă proastă aleasă de administratorul unui site. Problema era în PHP însuși.
Ce putea face un atacator?
Aici lucrurile devin serioase. În anumite condiții, vulnerabilitățile puteau permite unui atacator aflat undeva pe Internet să determine serverul să execute cod ales de el, fără să fie autentificat. În jargon se numește „unauthenticated remote code execution” — RCE.
Pentru cineva care nu lucrează în IT, cea mai simplă comparație ar fi aceasta:
Imaginați-vă un hotel. Site-ul este recepția, aplicațiile sunt angajații, iar serverul reprezintă clădirea, cu toate camerele, documentele și cheile ei. În mod normal, un străin poate intra doar în recepție și poate solicita lucrurile pe care recepția este autorizată să i le ofere.
O vulnerabilitate de tipul acesta poate transforma o cerere aparent banală făcută la recepție într-o cale prin care străinul ajunge în spatele tejghelei. Iar în cel mai rău scenariu nu mai discutăm despre deturnarea unui sit, ci despre posibilitatea de a executa comenzi pe server, de a accesa informații care nu ar trebui să fie publice, de a modifica date sau de a folosi sistemul compromis ca punct de plecare pentru alte atacuri.
De aceea un scor de 9,2 din 10 nu este ceva ce un administrator responsabil pune pe lista de „rezolvat când avem timp”.
De ce am închis eu serverul
În cazul meu, decizia a fost foarte simplă. Am oprit de bunăvoie serverul web în jurul orei 17 și l-am ținut oprit până aproape de ora 22. Au dispărut temporar de pe Internet toate domeniile găzduite acolo, inclusiv site-urile clienților.
Nu pentru că serverul fusese atacat. Ci tocmai pentru că nu voiam să aflu ulterior dacă fusese. Am preferat să actualizez toate versiunile PHP existente, să verific log-urile, sa fac scanări după modificări suspecte, să analizez procesele și abia după aceea să repornesc serviciile.
Mai pe scurt, decât să plângem toți mai târziu, mai bine să scâncească doi-trei pentru câteva ore că nu le merge site-ul.
Și, interesant, recomandarea de a scoate temporar sistemele de pe Internet atunci când actualizarea imediată nu este posibilă n-a fost vreo paranoia personală. Autorități europene și organizații naționale de securitate cibernetică au recomandat explicit izolarea sau chiar oprirea temporară a sistemelor expuse dacă patch-ul/update-ul nu putea fi aplicat imediat.
Uneori, cel mai bun firewall este cablul scos din priză.
Un pic de istoric: vulnerabilitățile nu s-au născut ieri
Aici povestea devine mult mai importantă decât două actualizări PHP.
Problemele de bază din mecanismele de gestionare a memoriei PHP sunt vechi. În 2020 fusese raportat inclusiv un comportament prin care anumite intrări puteau provoca epuizarea memoriei (OOM – Out Of Memory). În 2024 au reapărut probleme în aceeași zonă în cadrul unui audit.
Problema era că transformarea acestor comportamente într-un atac practic era considerată extrem de dificilă. Cu alte cuvinte, exista o diferență enormă între: „Teoretic, aici se poate întâmpla ceva rău” și „Pot să profit de povestea asta pentru a prelua de la distanță un server.”
Multă vreme, complexitatea atacului a funcționat ea însăși ca o barieră de securitate. Apoi a intrat în ecuație inteligența artificială.
AI-ul a făcut posibil ceea ce era considerat prea complicat
Cercetătorii care au investigat vulnerabilitățile au folosit modele AI avansate pentru a analiza problema și pentru a construi și adapta lanțurile necesare exploatării.
Wiz spune că modelele AI de frontieră au redus dramatic dificultatea problemei. OpenAI afirmă, la rândul său, că cercetătorii din proiectul „Patch the Planet” au folosit GPT-5.6 Sol pentru investigarea vulnerabilității, în timp ce Wiz a descoperit independent problemele folosind, printre altele, Gemini 4 Argon și GPT-5.6 Sol.
Rezultatul este probabil mai important decât vulnerabilitatea PHP în sine. O problemă poate exista într-un program de zece sau douăzeci de ani.
Dacă până acum puteam spune: „Da, teoretic este exploatabilă, dar ar necesita atât de multă muncă, atât de multă expertiză și un scenariu atât de complicat încât probabil nu merită efortul.”, această presupunere începe să nu mai valoreze mare lucru.
AI-ul reduce tocmai costul complexității. Ce necesita săptămâni sau luni de muncă pentru o echipă de specialiști poate ajunge să necesite zile sau ore pentru un cercetător foarte bun asistat de AI.
Ieri am văzut partea bună a fenomenului: AI-ul a ajutat cercetătorii să demonstreze problema, comunitatea de securitate s-a mobilizat, furnizorii importanți au fost avertizați, au fost pregătite protecții, iar echipa PHP a publicat actualizările.
Dar aceeași capacitate nu este rezervată doar „băieților buni”.
Și aici ajungem la digitalizare
De mai bine de 20 de ani mă ocup, într-o formă sau alta, de servere și tehnologii web.
Cu cât înțelegi mai bine cum funcționează lucrurile acestea, cu atât privești cu mai puțin entuziasm sloganul „să digitalizăm tot”.
Nu pentru că digitalizarea ar fi rea. Poate fi extraordinar de utilă. Dar: problema apare când confundăm digitalizarea cu mutarea cât mai rapidă a tuturor lucrurilor într-un calculator conectat la Internet: identitate digitală, acte, evidențe medicale, impozite, facturi, bănci, administrație, servicii publice, infrastructură, companii.
Fiecare serviciu digital nou înseamnă comoditate. Dar fiecare serviciu digital nou înseamnă și cod. Iar codul are vulnerabilități, care sunt descoperite uneori după o lună, alteori după douăzeci de ani.
Iar faptul că nimeni nu știe astăzi cum să exploateze o problemă nu mai reprezintă o garanție prea liniștitoare pentru mâine.
Digitalizarea nu elimină riscul. Îl concentrează.
Dacă o instituție are zece mii de dosare de hârtie în zece mii de sertare, accesarea lor ilegală la scară mare este dificilă.
Dacă aceleași zece mii de dosare se află într-o singură bază de date accesibilă printr-un sistem vulnerabil, situația se schimbă radical.
Avantajul digitalizării — faptul că putem procesa cantități enorme de informații foarte repede — este și unul dintre marile sale riscuri, Călcâiul lui Ahile – dacă vreți.
Un om poate fura un dosar. Un program poate fura un milion. Iar acum intrăm într-o perioadă în care inteligența artificială poate automatiza nu numai activitățile legitime, ci și căutarea vulnerabilităților, analiza codului și dezvoltarea unor atacuri.
Asta nu este un argument pentru rămânerea sau întoarcerea la hârtie, ci un argument pentru digitalizare făcută cu cap și fără grabă. Și nu pentru orice.
Identitatea personală, dosarul medical și banii nu sunt negociabile, dacă le digitalizăm sau nu. Cât timp sistemele informatice sunt supuse vulnerabilităților de orice fel, degeaba avem legi pentru protecția datelor personale.
GDPR-ul devine o glumă anostă cât timp un script kiddie îți poate face harcea-parcea o întreagă instituție, precum ANCPI. Și să nu uităm și de recentele evenimente din Franța, unde au dat vitrinele frigorifice pe programul de dezghețare în cateva zeci de supermarketuri, simultan.
Ieri am avut noroc și dintr-un alt motiv
Vulnerabilitățile au fost descoperite de cercetători care au colaborat cu cei care puteau să le repare. A existat ceea ce OpenAI numește o „Defender’s Window”: o perioadă în care apărătorii au avut informația și au putut pregăti patch-uri și mecanisme de protecție înainte ca problema să fie exploatată pe scară largă de atacatori.
PHP a publicat versiunile corectate 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Cloudflare pregătise deja reguli de protecție pentru infrastructura sa.
Autoritățile europene au emis avertizări iar administratorii au început să se preocupe de actualizări. Unii au oprit temporar site-uri și servicii. Am făcut și eu același lucru. Câteva ore mai târziu, serverul meu era din nou online.
Pentru utilizatorul obișnuit, probabil nu s-a întâmplat nimic. Și exact acesta este rezultatul pe care îl vrei de la securitatea informatică. Când oamenii care se ocupă de ea își fac treaba bine, pentru ceilalți nu se întâmplă nimic.
Dar ieri s-a schimbat ceva
PHP2Shell nu este interesant doar pentru că a afectat una dintre cele mai răspândite tehnologii ale Internetului. Este interesant pentru ceea ce ne spune despre următorii ani. Am intrat într-o perioadă în care argumentul că vulnerabilitatea există, dar este prea complicat de exploatat începe să expire.
AI-ul nu inventează neapărat vulnerabilitățile. Ele erau deja acolo. Dar poate transforma o problemă teoretică, ascunsă într-un munte de cod, într-o problemă practică.
Ieri AI-ul a fost de partea celor care au reparat-o. Data viitoare s-ar putea ca primii care găsesc problema să nu trimită un e-mail dezvoltatorilor.
Și tocmai de aceea, atunci când vorbim despre digitalizarea accelerată a statului, a economiei și, până la urmă, a vieții noastre, discuția n-ar trebui să fie doar despre cât de repede putem muta totul online.
Ar trebui să vorbim cel puțin la fel de serios despre cine păzește ceea ce mutăm acolo. Pentru că „digital” nu înseamnă automat „sigur”.
Iar uneori diferența dintre o zi obișnuită și o problemă foarte mare este un administrator care, pentru câteva ore, preferă să apese butonul OFF.
