PHP a publicat corecțiile pentru CVE-2026-109618 și CVE-2026-109619 pe 21 octombrie 2026. Majoritatea organizațiilor au tratat asta ca pe un exercițiu de patching și, până la finalul săptămânii, cele mai multe vor rula o versiune corectată.
A doua dintre cele două vulnerabilități merită însă o a doua discuție. Pe lângă execuția de cod la distanță, avertizarea PHP confirmă divulgarea de memorie — un atacator neautentificat care citește memoria heap a unui proces PHP. Imperva a măsurat aproximativ 67 KB de memorie recuperabilă printr-una dintre tehnicile demonstrate.
Un proces PHP deservește multe cereri de-a lungul vieții lui. Tot ce a trecut recent prin el se află în acea memorie: identificatori de sesiune, tokenuri de autentificare, credențiale de bază de date citite din configurație, chei de API pentru serviciile pe care le apelează aplicația, fragmente din cererile și răspunsurile altor utilizatori. O citire a acelei memorii nu este o citire a modelului tău de date. Este o citire a ce se întâmpla să fie în lucru.
Așa că întrebarea de după patching nu este doar „am corectat?". Este „ce ar fi putut pleca și putem înlocui?".
Ce confirmă efectiv avertizarea
Precizia contează aici, pentru că exagerarea este la fel de nefolositoare ca ignorarea.
PHP confirmă, pentru CVE-2026-109619, „use-after-free neautentificat în heap, divulgare de memorie și execuție de cod la distanță cu privilegiile procesului web". Execuția de cod a fost validată pe mod_php și, prin calea ciclului de viață al sesiunii, pe PHP-FPM.
Ce nu este stabilit este dacă ceva din toate acestea ți s-a întâmplat ție. Nu există indicatori de compromitere publicați pentru o citire reușită de memorie, iar o divulgare de acest tip nu lasă urmă în jurnalul aplicației, pentru că aplicația nu a rulat niciodată. În acest moment, niciunul dintre cele două CVE-uri nu figurează în catalogul CISA al vulnerabilităților exploatate cunoscute, iar CISA a declarat pe 21 octombrie că nu a observat exploatare. Telemetria furnizorilor se contrazice puternic — Hadrian a raportat exploatare „la scară", Imperva nu a văzut niciun trafic corespunzător în aceeași fereastră, iar watchTowr a văzut tentative, dar nicio reușită.
Combinația aceasta — capabilitate confirmată, dovezi absente în ambele sensuri — este terenul incomod pe care se iau deciziile reale.
De ce problema cade pe inventar, nu pe incident
O organizație care poate răspunde la „ce secrete deținea aplicația aceea, cine le-a emis și cum înlocuim fiecare dintre ele" tratează situația ca pe o săptămână de muncă planificată. O organizație care nu poate răspunde are o problemă mult mai mare, iar problema nu este PHP.
În practică, decalajul arată așa. Parola bazei de date este cunoscută, pentru că o mai schimbă cineva din când în când. Cheia de API a procesatorului de plăți este cunoscută, pentru că se află într-o procedură. Apoi urmează coada lungă: credențialele SMTP configurate în 2021, tokenul pentru serviciul intern de raportare, secretul de semnare a webhook-urilor, cheia pentru furnizorul de hărți, secretul de client OAuth pentru integrarea de single sign-on, certificatul folosit pentru TLS mutual către un partener. Fiecare a fost creat de cineva care între timp a plecat, și niciunul nu a fost rotit vreodată, pentru că nimic nu a forțat întrebarea.
Toate acestea intră direct sub articolul 21 din NIS 2, transpus în România prin OUG nr. 155/2024: politici privind criptografia, controlul accesului și gestionarea incidentelor. Un inventar de credențiale nu este un artefact separat de conformitate — este exact lucrul care face ca gestionarea incidentelor să fie executabilă.
Inventarul care face rotația posibilă
Patru coloane, completate pentru aplicațiile care contează. Nu un proiect.
- Ce este secretul și unde se află. Variabilă de mediu, fișier de configurare, seif de secrete sau scris direct în cod — iar dacă e ultima variantă, aceea este o constatare în sine.
- Cine l-a emis și cum se înlocuiește. Un portal al furnizorului, o autoritate de certificare internă, o consolă IAM din cloud, echipa de onboarding a unui partener. Include și cine are acces să facă înlocuirea.
- Ce se strică atunci când se schimbă. Este coloana pe care oamenii o sar și exact cea care decide dacă rotația se face marți la ora 10:00 sau niciodată. Dacă nimeni nu știe de ce este folosită o credențială, nimeni nu va risca să o rotească.
- Dacă poate fi rotită fără indisponibilitate. Unele sisteme acceptă două credențiale valide în timpul schimbării. Altele, nu. Să știi dinainte care în care categorie intră transformă o criză într-o secvență.
Testul util nu este dacă documentul există. Este dacă cineva l-ar putea executa săptămâna aceasta, fără ca singurul om care știe cum să fie disponibil.
Ce roteșți
Un răspuns proporțional, nu unul panicat. Rotește, aproximativ în ordinea asta:
- Tot ce deținea aplicația afectată în configurație — credențiale de bază de date, de cache și de cozi, parole ale conturilor de serviciu. Acestea erau, prin definiție, rezidente în memoria procesului.
- Tokenurile și cheile de API folosite de aplicație spre exterior, mai ales cele cu durată lungă. Dacă furnizorul acceptă credențiale de scurtă durată și tu nu le folosești, acesta este momentul să schimbi asta.
- Cheile de semnare și de criptare a sesiunilor, ceea ce invalidează sesiunile existente. Planifică impactul asupra utilizatorilor deliberat, nu descoperi-l.
- Certificatele și cheile private încărcate de procesul web, inclusiv certificatele de client pentru integrările cu parteneri. Reemite, nu doar redesfășura.
- Orice credențială care nu poate fi rotită fără fereastră de mentenanță — programeaz-o acum, în loc să o mai porți ca excepție cunoscută încă doi ani.
Ce poți depriorititza rezonabil: credențialele care nu au fost niciodată deținute de serverele afectate și orice are deja o durată de viață suficient de scurtă încât fereastra să fi trecut.
O posibilă divulgare este incident raportabil?
Aici organizațiile vor un da sau un nu, iar răspunsul onest este că depinde de ce poți stabili.
Sub NIS 2, transpus prin OUG nr. 155/2024, obligația de raportare se atașează unui incident semnificativ, cu termenele de 24 de ore pentru avertizarea timpurie și 72 de ore pentru notificare. O capabilitate teoretică, cu sistemele tale corectate și fără dovezi de exploatare, în general nu este așa ceva. Dovada că traseul vulnerabil a fost exercitat împotriva infrastructurii tale este cu totul altceva — și exact de aceea merită ca analiza jurnalelor să fie făcută serios, nu formal.
Sub articolul 33 din GDPR, întrebarea este dacă s-a produs o încălcare a securității datelor personale, notificabilă în 72 de ore, cu excepția cazului în care este puțin probabil să genereze un risc. Divulgarea de memorie dintr-un proces care a deservit sesiuni autentificate ar putea implica date personale — dar „ar fi putut" nu este „a fost", iar regulamentul întreabă despre o încălcare reală, nu despre o vulnerabilitate.
Poziția apărabilă în ambele regimuri este aceeași: documentează ce ai verificat, ce ai găsit, când ai corectat, ce ai rotit și raționamentul din spatele deciziei de clasificare. O decizie consemnată împreună cu temeiul ei este un proces funcțional, chiar și atunci când concluzia este „neraportabil". O decizie pe care nu a scris-o nimeni nu se deosebește de a nu fi căutat deloc.
Dacă ai găsit dovezi de exploatare, ambele analize se schimbă, iar termenele curg din momentul în care ai luat cunoștință — nu de la publicarea CVE-ului.
Ce îți pot și ce nu îți pot spune jurnalele
Avertizarea PHP include o procedură de audit, iar avertismentul ei este partea importantă: „absența unei erori în jurnale nu este dovadă de siguranță."
Procedura, pentru o fereastră de audit izolată: setează log_errors=On cu un error_log funcțional și error_reporting=E_ALL, apoi analizează jurnalele serverului web, ale PHP-FPM și ale proxy-ului pentru avertismente, notificări de depreciere și erori de nucleu care apar repetat înainte de rularea scripturilor vizate; diagnostice ridicate în timpul curățării extensiilor sau a serverului; erori fatale, de parsare și neprinse; „Maximum execution time exceeded"; și eșecuri limitate la rute sau tipuri de conținut controlate de atacator.
CISA adaugă semnalul comportamental care merită alertat oricum: procese PHP care lansează shell-uri sau descarcă unelte.
Corelight a publicat notificări Zeek și reguli Suricata pentru detecție, iar CERT-EU trimite către o listă întreținută de comunitate cu software terț care încorporează PHP — utilă pentru echipamentele și produsele de la furnizori pe care nimeni nu le numără ca parc PHP.
Partea care se generalizează
La câteva luni apare aceeași întrebare: o vulnerabilitate care ar fi putut expune credențiale, fără să fi făcut-o cu certitudine. Vulnerabilitatea de citire de fișier din Atlassian, de la începutul lunii, a fost o versiune mai curată a aceleiași situații — citești un fișier de configurare, obții credențialele din el, iar singurul răspuns onest este să le roteșți.
Ce diferențiază organizațiile în momentul acela nu este detecția și nu sunt uneltele. Este dacă cineva poate spune ce secrete există, cine le emite și ce se strică atunci când se schimbă. Răspunsul acela se construiește într-o săptămână obișnuită sau deloc.
Acolo unde inventarul în sine este lipsa, un audit de conformitate sub NIS 2 acoperă ce se așteaptă un evaluator să vadă și ce dovezi îl satisfac. Acolo unde întrebarea este la ce ajunge un atacator odată ce deține o singură credențială recuperată, un test de penetrare intern răspunde direct. Iar acolo unde nu ești sigur ce PHP publici, o evaluare a suprafeței externe de atac construiește lista din exterior, așa cum o face un atacator.
Surse: Anunțul de lansare PHP din 21 octombrie 2026 · Înregistrarea CVE-2026-109619 · Fișa NVD pentru CVE-2026-109619 · Analiza watchTowr · Conținut de detecție Corelight
Capabilitatea de divulgare a memoriei este confirmată în avertizarea PHP; dacă a fost exercitată împotriva unei anumite organizații nu este stabilit, iar pentru o citire reușită nu există indicatori de compromitere. Rapoartele furnizorilor privind exploatarea se contrazic și niciunul nu a publicat cifre. La momentul redactării, niciunul dintre CVE-uri nu figura în catalogul CISA al vulnerabilităților exploatate cunoscute. Cifra de ~67 KB este măsurătoarea Imperva pentru una dintre tehnicile demonstrate.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.