O vulnerabilitate veche, făcută exploatabilă de AI
Vulnerabilitățile, înregistrate ca CVE-2026-109618 și CVE-2026-109619, se regăsesc în PHP de mai bine de zece ani, iar semnalele au existat cu mult înainte de momentul de acum. Potrivit Calif, firmă de AI red-teaming din California, comportamentul care stă la baza problemei a fost semnalat într-un bug report încă din 2020, fără urmări. În 2024, în timpul primului audit extern de securitate al PHP, un dezvoltator din echipa de bază a observat primele semne ale vulnerabilității, după cum confirmă chiar PHP Foundation. Atunci nu s-a găsit o cale concretă de exploatare, iar patch-ul a fost amânat.
Anul acesta, modelele AI de ultimă generație au schimbat situația. Wiz, Google, OpenAI și Calif au descoperit vulnerabilitățile în august, cu ajutorul AI, și le-au ținut confidențiale până când update-urile au fost pregătite. Wiz descrie momentul ca pe un punct de inflexiune, în care AI-ul a transformat un cod vulnerabil vechi de peste zece ani într-un atac funcțional.
Ce înseamnă vulnerabilitatea PHP2Shell pentru orice business digital
CERT-EU, echipa de răspuns la incidente de securitate a instituțiilor Uniunii Europene, a evaluat ambele vulnerabilități cu scorul CVSS de 9,2. În anumite condiții, ele permit unui atacator să ruleze cod pe server de la distanță, fără autentificare, și să citească din memoria serverului informații precum parole, chei API sau certificate.
Pentru o companie, riscul se traduce în date ale clienților expuse, servicii care pot fi oprite și acces la sistemele conectate. Pentru că vulnerabilitatea se află în PHP, platforma pe care rulează aplicațiile, o companie poate fi expusă chiar dacă propriul cod este scris și întreținut corect.
Evaluările experților s-au nuanțat pe măsură ce au apărut mai multe date. Amazon Threat Intelligence a înregistrat o primă tentativă de exploatare pe 17 octombrie, cu patru zile înaintea dezvăluirii publice.
Pe 22 octombrie, Sansec, companie specializată în securitatea platformelor de e-commerce, a apreciat că o exploatare în masă e mai puțin probabilă decât se estima inițial, pentru că un atac are nevoie de cunoștințe specifice despre serverul vizat și de anumite condiții de configurare. În același timp, companii de securitate precum watchTowr au raportat tentative active de exploatare, iar agenția americană de securitate cibernetică CISA nu observase exploatări la momentul alertei sale din 21 octombrie. Pentru o companie, concluzia rămâne aceeași, pentru că riscul e real și update-ul are prioritate.
Organizațiile mari au reacționat pe măsură. Wikimedia Foundation, care operează Wikipedia, a scos temporar din funcțiune o parte dintre sisteme, ca măsură de precauție, iar în România, DNSC a emis o alertă pentru cele două vulnerabilități.
O săptămână cu incidente critice în lanț
PHP2Shell nu a fost singurul incident major al săptămânii. Tot între 17 și 20 octombrie, s-a aflat că cheile private ale opt certificate au fost compromise. Astfel de chei pot fi folosite pentru a emite certificate false pentru site-uri pe care atacatorul nu le controlează.
Browserele majore au blocat certificatele afectate, eMudhra le-a revocat, iar proiecte precum Composer, managerul de pachete al ecosistemului PHP, și-au actualizat listele de certificate de încredere. Potrivit eMudhra, doar unul dintre cele opt certificate era folosit în producție și niciunul nu emisese certificate către utilizatori finali.
În paralel, GitLab, platformă de dezvoltare software și CI/CD, a lansat în octombrie update-uri pentru vulnerabilitatea CVE-2026-97229, cu scorul maxim de 10, după ce o altă vulnerabilitate cu același scor, CVE-2026-85706, fusese exploatată activ în septembrie. Pentru experții Zitec, succesiunea acestor incidente arată că vulnerabilitățile critice au devenit o constantă, iar avantajul îl au organizațiile care își țin întregul stack tehnologic la zi și au un proces clar atât de prevenție, cât și de reacție.
Expunerea cea mai mare vine din versiunile vechi
Update-urile oficiale acoperă versiunile PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. PHP 8.1 și versiunile mai vechi au ajuns la end-of-life, iar pentru PHP 7.4, 8.0 și 8.1 au fost publicate doar backport-uri minimale de cod sursă, care trebuie integrate și testate de fiecare echipă.
Distribuțiile Linux și furnizorii de suport pe termen lung au primit patch-urile înaintea lansării publice, așa că organizațiile care folosesc astfel de pachete trebuie să verifice update-urile direct cu furnizorul. Potrivit W3Techs, versiunea 7 rulează încă pe 26,9% dintre site-urile PHP, iar versiunea 5 pe 7,7%, ceea ce înseamnă că o parte semnificativă din web rulează pe versiuni pentru care nu există o versiune oficială actualizată.
„Versiunile vechi sunt locul în care riscul rămâne după ce trece urgența. Fiecare sistem care rulează PHP 8.1 sau mai vechi are nevoie de un plan clar, fie de migrare pe o versiune suportată, fie de măsuri extra preventive până la o soluție definitivă. Noi deja testăm intern versiuni de imagini pentru PHP 8.1, 8.0 și 7.4 cu fixurile de securitate incluse și ne dorim să le ducem în producție cât mai rapid pentru clienții noștri”, spune Marius Bălteanu, CIO Zitec.
Zitec folosește AI în dezvoltarea acestei soluții și va comunica public progresul.
Pregătirea face diferența în primele ore
Experiența ultimelor zile confirmă că viteza de reacție depinde de infrastructura construită dinainte. Pe proiectele pe care le operează pentru clienți, Zitec a răspuns în două etape. Înaintea publicării update-urilor oficiale, echipa de incident a urmărit în timp real informațiile din surse verificate și a aplicat măsuri țintite, inclusiv reguli de WAF, care au protejat aplicațiile împotriva tentativelor de exploatare. În paralel, echipa a aplicat o măsură separată pentru incidentul eMudhra.
În a doua etapă, în 15 minute de la publicarea imaginilor PHP actualizate, pipeline-urile automate au generat imaginile specifice fiecărui proiect, iar echipele le-au verificat, testat și lansat în mediile de producție. Proiectele au rămas cu zero atacuri confirmate până la data publicării.
Asta a fost posibil datorită investițiilor făcute în ultimele luni în securitate și automatizare. Proiectele rulează pe imagini standardizate, iar o automatizare propagă în cascadă fiecare actualizare, de la imaginea de bază până la nivel de aplicație. Echipa a dezvoltat automatizarea cu ajutorul AI, iar ea rulează fără AI, ceea ce o păstrează previzibilă și ușor de verificat tocmai în momentele critice.
„Într-o situație ca aceasta, diferența o face munca făcută cu mult înainte. Când update-ul oficial a apărut, automatizarea l-a dus pe toate proiectele, iar echipa s-a putut concentra pe verificare și pe comunicarea cu clienții”, adaugă Marius Balteanu.
Ce recomandă experții
Primul pas este instalarea update-ului PHP cât mai curând. Vulnerabilitățile se află în limbajul în sine, așa că actualizarea codului aplicației sau a plugin-urilor nu le acoperă.
Un Web Application Firewall pus în fața aplicațiilor expuse blochează tiparele de atac cunoscute și câștigă timp până la update. Experiența acestor zile a arătat că WAF-ul a devenit un instrument critic pentru monitorizarea traficului, atât înainte, cât și după aplicarea update-ului, pentru că arată ce tentative ajung la aplicații.
Cloudflare a livrat reguli dedicate inclusiv pe planul gratuit, cu aproximativ nouă ore înainte de dezvăluirea publică, iar echipa Zitec lucrează cu astfel de soluții specializate, precum Cloudflare și Google Cloud Armor. Totuși, WAF-ul rămâne o apărare suplimentară, iar Cloudflare își descrie propriile reguli drept o soluție temporară, ajustată pe măsură ce atacatorii își schimbă metodele.
Incidentul eMudhra adaugă o recomandare pentru toate companiile, indiferent dacă folosesc sau nu PHP: listele de certificate de încredere din aplicații, biblioteci și containere trebuie actualizate odată cu restul stack-ului tehnologic, pentru că browserele s-au protejat automat, dar multe aplicații au nevoie de un update explicit.
Pe termen lung, experții Zitec recomandă companiilor să trateze update-urile, protecția aplicațiilor și planul de reacție ca parte din strategia de business. Într-o perioadă în care AI-ul accelerează atât descoperirea vulnerabilităților, cât și exploatarea lor, de aceste decizii depind direct încrederea clienților și continuitatea serviciilor.
