PHP sub foc: CVE-2026-109618 și CVE-2026-109619 permit execuție de cod la distanță pe orice server web

Două vulnerabilități critice în PHP, notate 9.2 pe CVSS 4.0, transformă o eroare de memorie într-o cale de execuție de cod neautentificată. Peste 22 de milioane de instanțe expuse și deja proof-of-concept public.

PHP rulează, discret, pe o bună parte din internetul pe care îl folosim zilnic — de la bloguri WordPress și magazine online până la panouri de administrare și API-uri interne. Pe 21 octombrie 2026, PHP Group a publicat o actualizare de securitate pentru două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, care permit unui atacator neautentificat să execute comenzi pe serverul web. NCSC din Marea Britanie a emis o alertă, Unit 42 a confirmat existența unor proof-of-concept, iar cel puțin un guvern european și-a scos site-ul offline preventiv. Dacă infrastructura ta atinge PHP, acesta este momentul să citești cu atenție ce urmează.

Ce s-a întâmplat, pe scurt

PHP a publicat un update de securitate care remediază o problemă critică ce poate permite atacatorilor să execute comenzi pe orice server web care rulează PHP. Ambele vulnerabilități sunt evaluate cu 9.2 pe scala CVSS 4.0 și sunt clasificate drept execuție de cod la distanță (RCE). Nu vorbim despre o eroare care necesită autentificare, un plugin vulnerabil sau o configurație exotică: vectorul de atac este, în principiu, o simplă cerere HTTP care declanșează o condiție de memorie insuficientă (out-of-memory) în interpretor.

Problema a fost remediată, însă remedierea nu se aplică singură. NCSC subliniază explicit că orice versiune de PHP este afectată, iar organizațiile care rulează versiuni vechi, scoase din suport, sunt încurajate să treacă la o versiune complet suportată. Cu alte cuvinte, nu te poți liniști gândindu-te că ai actualizat acum doi ani.

Mecanismul din spatele celor două CVE-uri

Ambele vulnerabilități au aceeași rădăcină conceptuală: modul în care PHP tratează erorile fatale și epuizarea memoriei prin mecanismul longjmp(). Când ceva merge prost la nivel de memorie, interpretorul „sare” peste stiva normală de execuție pentru a curăța requestul — dar curățenia aceasta se face pe un teren care nu mai este de încredere.

CVE-2026-109618: memoria care nu apucă să se inițializeze

Aici, gestionarea unei condiții out-of-memory poate întrerupe PHP în timp ce datele interne ale requestului sunt doar parțial inițializate. La curățarea requestului, codul tratează acele date invalide ca și cum ar fi valide. Unit 42 descrie mecanismul ca o gestionare defectuoasă a fluxului de control, care lasă memoria requestului neinițializată — un atacator poate declanșa în mod repetat condiții OOM pentru a obține execuție de cod în mod fiabil.

CVE-2026-109619: starea care supraviețuiește memoriei eliberate

A doua vulnerabilitate este, dacă vrei, și mai insidioasă. Starea internă deținută de un request poate supraviețui după ce memoria care o susținea a fost eliberată. Un request ulterior, procesat de același worker, poate folosi acea stare „stale” înainte ca inițializarea normală să o reseteze. Este clasicul use-after-free care, într-un server web cu workers persistenți, devine o punte între cereri: un atacator nu trebuie să lovească aceeași conexiune, ci doar același proces.

Important: ambele vulnerabilități sunt notate 9.2 pe CVSS 4.0 și permit execuție de cod fără autentificare. Nu este o problemă de „hardening”, este o problemă de patch urgent.

Cât de mare este suprafața de atac

Cifrele sunt, de departe, partea cea mai incomodă a acestei povești. Palo Alto Networks Cortex Xpanse a identificat, pe baza telemetriei proprii, peste 22,6 milioane de instanțe expuse care ar putea fi vulnerabile la cele două CVE-uri. Vorbim despre sisteme vizibile din internet, nu despre laboratoare interne. Iar atunci când un proof-of-concept există deja și un guvern își scoate site-ul offline ca măsură de precauție, fereastra de grație se măsoară în ore, nu în săptămâni.

Complicația suplimentară vine din faptul că PHP nu apare doar acolo unde te aștepți. NCSC-NL a publicat un inventar de produse software cu dependență de PHP care ar putea fi afectate — iar lista include aparate și servicii care împachetează PHP ca componentă internă, fără ca echipa ta să fi instalat vreodată PHP în mod explicit. Un appliance de backup, un panou de management, un CMS auto-găzduit: toate pot ascunde un interpretor PHP pe care nimeni nu îl urmărește în procesul de patch management.

Atenție: nu limita inventarul la versiunile vechi de PHP. Toate versiunile pot fi afectate, deci trebuie să identifici instalările PHP în general, cu prioritate pe cele expuse în internet.

Ce faci concret, în ordinea priorităților

NCSC recomandă o serie de acțiuni prioritare, iar noi le-am ordonat după impactul practic pe care îl vedem în evaluările noastre. Prima și cea mai importantă este inventarierea: identifică sistemele care rulează PHP în întreaga infrastructură, cu accent pe cele orientate spre internet. Nu te baza doar pe CMDB — scanează, întreabă echipele de produs, verifică aparatele.

1. Identifică toate instalările PHP, inclusiv cele ascunse în appliance-uri și servicii terțe.
2. Actualizează la ultima versiune PHP care conține remedierea și monitorizează în continuare apariția de update-uri.
3. Monitorizează furnizorii terți pentru actualizări, inclusiv pentru echipamentele care împachetează PHP.
4. Aplică pașii suplimentari de hardening recomandați de echipa PHP.
5. Folosește mitigările temporare oferite de echipa PHP dacă actualizarea nu este imediat posibilă.
6. Scoate offline sistemul dacă nici mitigările nu pot fi aplicate în timp util.

Un detaliu care merită subliniat: dacă nu poți actualiza sau dezactiva sistemul imediat, NCSC recomandă să îl evaluezi pentru semne de compromitere înainte de upgrade sau de mitigare și să cauți backdoor-uri instalate de atacator. Este o inversare subtilă a logicii obișnuite: nu patch-uiești și apoi te întrebi dacă ai fost lovit, ci verifici mai întâi, pentru că un atacator care a exploatat deja vulnerabilitatea poate supraviețui patch-ului.

Hardening și mitigări temporare

Echipa PHP a publicat atât pași suplimentari de hardening, cât și mitigări temporare pentru cei care nu pot aplica imediat update-ul. În practică, acestea reduc suprafața de atac, dar nu înlocuiesc patch-ul — tratează-le ca pe un bandaj care îți cumpără timp, nu ca pe o soluție. Dacă mitigarea ar dura prea mult sau nu poate fi aplicată, varianta recomandată este simplă și neplăcută: scoate sistemul din producție până când poate fi remediat complet.

# verifică rapid versiunea PHP pe un host
php -v

# identifică pachetele PHP instalate (Debian/Ubuntu)
dpkg -l | grep -i php

# verifică dacă serviciul web expune PHP
curl -sI https://exemplu.ro/index.php

De ce contează pentru echipa ta, nu doar pentru administratorul de server

Este ușor să privești această alertă ca pe o problemă de „sysadmin”. Dar consecințele se propagă mult mai departe. Execuție de cod la distanță pe un server web înseamnă acces la baza de date a aplicației, la chei API, la secrete de configurare și, de acolo, o cale de mișcare laterală către restul rețelei. NCSC recomandă explicit ghidajul privind prevenirea mișcării laterale tocmai pentru că un server web compromis este, aproape întotdeauna, doar primul pas.

În evaluările noastre de penetrare, tocmai astfel de vulnerabilități în componente de infrastructură — interpretori, biblioteci, runtime-uri — se dovedesc cele mai valoroase pentru un atacator, pentru că nu apar în lista de priorități a echipei de aplicații. Nimeni nu „deține” PHP-ul din spatele unui CMS. Iar când nimeni nu îl deține, nimeni nu îl patch-uiește la timp.

Un alt unghi important este cel al lanțului de aprovizionare software. Dacă produsul tău împachetează PHP, clienții tăi depind de viteza cu care tu publici un update. NCSC recomandă principiile pentru pipeline-uri securizate de build și deployment, iar acest incident este un exemplu perfect pentru de ce: o dependență de runtime compromisă se propagă la fiecare client care instalează versiunea ta.

Ce urmează și cum te pregătești

NCSC va continua să monitorizeze impactul asupra organizațiilor din Marea Britanie, iar Unit 42 oferă protecții pentru clienții proprii — semnătura Threat Prevention 543004 pentru Advanced Threat Prevention Plus cu Frontier Virtual Patching, detectarea versiunilor vulnerabile prin Cortex Cloud Posture și Prisma Cloud Compute, și identificarea instanțelor expuse prin Cortex Xpanse. Pentru organizațiile care nu folosesc aceste platforme, lecția rămâne aceeași: ai nevoie de vizibilitate asupra a ceea ce rulează în infrastructura ta și de un proces care transformă o alertă într-un patch aplicat, nu într-un ticket uitat.

Recomandarea noastră practică este să tratezi acest eveniment ca pe un exercițiu de maturitate. Inventarul PHP pe care îl construiești acum îți va folosi și la următoarea vulnerabilitate dintr-un runtime sau o bibliotecă. Iar decizia de a verifica sistemele pentru compromitere înainte de patch — nu după — este exact diferența dintre o organizație care reacționează și una care rămâne compromisă fără să știe. Dacă nu ai încredere în capacitatea internă de a face această verificare, NCSC recomandă apelarea la un furnizor acreditat de răspuns la incidente; mai important decât cine o face este să se facă înainte de a închide fereastra.