PHP2Shell: CVE-2026-109618 și CVE-2026-109619, două defecte critice PHP. Fixurile apar de la 14:00 UTC pe 21 octombrie. Ce faci azi

• SecurityWeek relatează, pe 23 octombrie, că nu există încă nicio compromitere confirmată prin PHP2Shell. Sophos a văzut tentative de instalare a unei variante Mirai numite „Potassium” și și-a corectat o actualizare anterioară care raportase o exploatare reușită; Hunt.io leagă traficul de un botnet de tip Mirai activ din mai 2026, iar Arctic Wolf nu vede în datele sale livrarea efectivă. Wordfence nu raportează compromiteri.
• VulnCheck spune că exploit-ul său pentru CVE-2026-109618 ocolește ASLR pe x86-64 cu afișarea erorilor oprită, o configurație recomandată în producție. Exploit-ul nu este public, iar VulnCheck spune că puține dintre sutele de depozite „PoC” de pe GitHub sunt legitime. Afirmația nu poate fi verificată independent.
• Sansec și-a revizuit predicția de exploatare în masă: exploit-urile publice eșuează pe setările implicite. Amazon a observat prima tentativă pe 17 octombrie, înaintea corecturilor.
• Potrivit SecurityWeek, mai multe site-uri guvernamentale, școlare și de spitale din Europa au fost oprite pe 21 octombrie, iar Marea Britanie a raportat 32 de servicii guvernamentale indisponibile și 4 parțial, în majoritate ca măsură de precauție în timpul corectării. Aceasta confirmă și nuanțează relatarea din 22 octombrie.
• Qualys, pe date anonimizate de la clienții săi, spune că doar circa 199.000 de instanțe PHP au fost corectate în primele 12 ore și că majoritatea rulează ramuri ieșite din suport. Sunt date ale unui singur furnizor. La 23 octombrie, CISA nu adăugase defectele în catalogul KEV.
• Concluzia practică nu se schimbă: actualizează și verifică. Lipsa compromiterilor confirmate nu înseamnă lipsa riscului, iar ramurile vechi nu primesc corecturi.

• CISA a publicat pe 21 octombrie o alertă cu îndemn la corectare imediată. Spune că nu a observat exploatare a CVE-2026-109618 și CVE-2026-109619 la data publicării și nu dă un termen. Cere inventarierea tuturor sistemelor cu PHP, inclusiv a PHP încorporat în alte produse, corectare cu prioritate pe sistemele expuse, scoaterea din funcțiune a celor care nu pot fi actualizate sau rulează PHP 8.1 și mai vechi, un WAF ca măsură intermediară și monitorizarea proceselor PHP care lansează shell-uri sau descarcă unelte.
• DNSC a publicat pe 21 octombrie alerta „Vulnerabilități critice în PHP”. Nu am putut citi conținutul paginii; o menționăm după titlu și dată.
• Krebs on Security a relatat că Cloudflare spune că a detectat deja o parte din exploatare, ceea ce contrastează cu observația CISA de la data publicării ei; sursele nu se contrazic neapărat, ci surprind momente diferite. Același articol citează, fără sursă, că „aproape 70%” dintre site-uri ar avea de actualizat, cifră pe care o tratăm ca neverificată, și notează relatări Reuters despre site-uri guvernamentale din Europa căzute după dezvăluire, fără cifre. Un titlu din presa indiană leagă căderea unor site-uri guvernamentale europene de defect; nu l-am putut verifica.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): PHP folosește longjmp() pentru a întrerupe cererea la epuizarea memoriei. În anumite contexte, memoria cererii este accesibilă înainte să fie complet inițializată, iar la închiderea cererii PHP citește sau ramifică după o stare invalidă. Avizul spune că poate duce la RCE neautentificat cu contul procesului web și raportează un RCE validat împotriva Apache mod_php cu limitele implicite. PHP-FPM este considerat probabil susceptibil, fără un exploit complet demonstrat, la fel FrankenPHP și LSAPI.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): stare globală păstrată de worker poate indica memorie eliberată a unei cereri anterioare, iar unele operații dinainte de inițializarea cererii o consumă, ceea ce duce la use-after-free, dezvăluire de memorie și RCE. Avizul confirmă RCE împotriva mod_php prin calea de backtrace la erori fatale din PHP 8.5 și validează calea de progres al încărcării sesiunii (session upload progress) pe mod_php și PHP-FPM.
• Scor: CVSS v4.0 de 9,2 pentru fiecare (vector AV:N, PR:N, UI:N, impact ridicat asupra confidențialității, integrității și disponibilității).
• Versiuni afectate: cele mai vechi decât 8.2.35, 8.3.36, 8.4.27 și 8.5.12, care sunt versiunile corectate. Avizele nu enumeră ramurile mai vechi.
• Singura remediere completă este actualizarea. Avizul pentru CVE-2026-109619 spune că nu există o mitigare completă prin configurare.
• Fixurile pentru ramurile 7.4, 8.0 și 8.1, neacceptate de proiect, există sub formă de corecturi sursă minimale pentru cine compilează din sursă, potrivit Help Net Security și BleepingComputer. Distribuțiile Linux și furnizorii LTS au primit corecturile înainte de lansarea publică; verifică pachetul furnizorului tău.
• NCSC din Marea Britanie spune că sunt afectate organizațiile care folosesc orice versiune de PHP și îndeamnă la actualizare imediată sau, dacă nu se poate, la scoaterea sistemului din funcțiune până la mitigare. Cere inventarierea tuturor instalărilor, cu prioritate pentru cele expuse în internet, nu doar a celor vechi.

• Exploatare: directorul tehnic Cloudflare, Dane Knecht, a spus, potrivit BleepingComputer, că firma vede atacuri timpurii vizând ambele defecte și a pus reguli WAF temporare pentru toți clienții, inclusiv pe planul gratuit. Este o declarație relatată, fără detalii despre moment sau amploare. Echipa PHP spune că există un exploit demonstrat pentru mod_php; nu este clar dacă este public. Tenable notează că în circulație este cod de exploatare neverificat, care poate conține malware. Nu rula coduri de exploatare primite din surse neverificate.
• watchTowr a spus pe 20 octombrie că a reprodus CVE-2026-109618, nu și CVE-2026-109619, și că nu observase exploatare. NCSC-NL nu afirmă explicit exploatare în lume și cere monitorizarea activității publice de exploatare.
• Scurgerea: potrivit BleepingComputer, informațiile fuseseră sub embargo, iar un mesaj șters de pe Hacker News a vorbit despre CVSS 10,0, dezvăluire pe 22 octombrie și versiuni de la PHP 5 încolo. Scorul oficial este 9,2. Tenable notează că CERT-EU și un clip demonstrativ vorbesc despre versiuni începând cu PHP 5.4.0; avizele PHP enumeră oficial doar ramurile pe care le-a corectat.
• Expunerea: VirusTotal estimează peste 5,1 milioane de gazde PHP expuse, iar Tenable citează estimări de circa 1,3 milioane și peste 1,9 milioane. Sunt estimări cu metode diferite; o gazdă expusă nu este neapărat vulnerabilă.
• Cine le-a raportat: cercetători de la Calif, Wiz și OpenAI, potrivit BleepingComputer, iar avizele numesc mai mulți raportori. Atribuirea exploatării nu există.

Combinația este neplăcută: RCE fără autentificare, într-o componentă prezentă aproape peste tot, cu detalii deja scurse, un exploit demonstrat și atacuri timpurii raportate. Din momentul publicării avizelor, atacatorii pot compara corecturile și construi exploit-uri.

Pe de altă parte, ordinea contează. Nu toate instalările PHP sunt la fel de expuse: PHP rulat din linie de comandă pentru sarcini interne nu primește cereri web, în timp ce un site cu Apache mod_php este cazul cel mai riscant, potrivit PHP. Inventarul decide ordinea.

• Inventariază instalările PHP: servere, containere și imagini de bază, găzduire partajată, panouri de administrare, aparate și produse ale furnizorilor care includ PHP. NCSC-NL a publicat un inventar de produse posibil afectate. Verifică versiunea (php -v) și modul de rulare (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed).
• Prioritizează sistemele expuse în internet, apoi cele interne cu acces la date sensibile.
• Actualizează la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, sau instalează pachetul corectat al furnizorului distribuției. Reconstruiește imaginile de container, repornește toți workerii PHP și confirmă că procesele care rulează încarcă versiunea nouă, nu doar că pachetul e instalat.
• Dacă nu poți actualiza imediat, aplică mitigările temporare din avizele PHP, știind că nu sunt complete: dezactivează session.upload_progress.enabled și repornește workerii; pe PHP 8.5 setează fatal_error_backtraces=0; pune memory_limit=-1 impus la nivel de pool sau server, setează un post_max_size mic și limitează încărcările; blochează cererile multipart la frontend dacă aplicația nu le folosește.
• Pune reguli WAF ca măsură intermediară (de exemplu cele ale Cloudflare, care acoperă doar traficul trecut prin ele). Nu înlocuiesc actualizarea.
• Pentru sistemele pe care nu le poți corecta rapid și care sunt expuse, ia în calcul scoaterea lor din internet până la mitigare, așa cum recomandă NCSC.
• Pentru PHP 7.x și 8.1 sau mai vechi: cere furnizorului un backport sau folosește corecturile sursă minimale, apoi planifică migrarea. O aplicație veche, fără actualizări, rămâne expusă la tot ce urmează.
• Dacă ai găzduire partajată sau un MSP: cere-le în scris dacă au actualizat, când și ce versiune rulează pentru tine.

Pentru că atacuri timpurii sunt raportate, nu presupune că ești curat doar pentru că ai actualizat acum. NCSC recomandă, dacă nu poți actualiza sau dezactiva sistemul imediat, să cauți semne de compromitere și backdoor-uri.

Concentrează-te pe contul procesului web: fișiere noi sau modificate în directoarele aplicației (în special .php în locuri de încărcare), procese copil neobișnuite ale PHP, conexiuni de ieșire noi, cereri multipart anormale în jurnale și reporniri neașteptate ale workerilor. Păstrează jurnalele înainte de modificări. Avizul PHP precizează că jurnale curate nu dovedesc siguranța. Dacă găsești ceva, tratează sistemul ca incident: izolează, investighează, rotește secretele accesibile contului web (chei API, parole de baze de date) și raportează.

• Cine poate aproba o actualizare de urgență în afara ferestrei de mentenanță și în cât timp? Decide înainte să fie nevoie.
• Care sunt site-urile și aplicațiile critice pe PHP (magazin online, portal, CRM, panouri de administrare) și cine răspunde de fiecare?
• Ce furnizori îți administrează PHP-ul și ce termene au promis? Cere confirmare pentru azi.
• Ce spui conducerii în seara asta: ce am inventariat, ce am corectat, ce rămâne expus și ce măsuri temporare sunt active.

NIS2 cere gestionarea vulnerabilităților și a riscurilor din lanțul de aprovizionare. Dacă găsești o compromitere, entitățile esențiale și importante au avertizarea timpurie în 24 de ore și raportul inițial în 72 de ore pentru incidente semnificative; pentru date personale, GDPR cere notificare în 72 de ore dacă riscul o impune. Aplicabilitatea depinde de situația ta; verifică cu juristul sau cu responsabilul cu protecția datelor.

Avizele PHP sunt sursa primară pentru defecte, versiuni corectate și mitigări. NCSC din Marea Britanie și NCSC-NL sunt surse autoritative pentru recomandări. Cloudflare, watchTowr și Tenable sunt surse pentru exploatare și scurgere, relatate prin presă, iar cifrele de expunere sunt estimări. Situația se schimbă rapid; verifică din nou avizele PHP și ale furnizorului tău.

Awarely Monitor poate ajuta la evidența instalărilor PHP expuse și la prioritizarea remedierii după exploatare, nu după număr de CVE-uri. Awarely Learning susține exercițiile pentru conducere: cine decide o actualizare de urgență și cum comunicăm. Articolul nu este consultanță juridică și nu garantează conformitatea.