Două vulnerabilități critice în PHP amenință securitatea site-urilor web. Cum pot fi eliminate

Două vulnerabilități grave descoperite în limbajul PHP permit, în anumite condiții, executarea de cod malițios de la distanță, fără autentificare. Dezvoltatorii PHP au publicat pe 21 octombrie 2026 actualizări de securitate de urgență, iar organizațiile specializate recomandă instalarea imediată a acestora. Sunt vizate inclusiv serverele care găzduiesc site-uri WordPress, platforme editoriale, magazine online și alte aplicații dezvoltate în PHP.

Două vulnerabilități cu nivel critic de severitate

Pe 21 octombrie 2026, echipa de dezvoltare PHP a anunțat remedierea a două vulnerabilități critice, identificate prin codurile CVE-2026-109618 și CVE-2026-109619. Ambele au primit un scor de severitate CVSS v4.0 de 9,2 din 10, ceea ce le plasează în categoria amenințărilor critice.

Problemele afectează mecanisme fundamentale ale interpretorului PHP, în special administrarea memoriei și gestionarea stărilor interne ale proceselor. În anumite configurații, atacatorii pot exploata aceste deficiențe pentru a executa comenzi sau programe neautorizate pe server, fără să dețină un cont de utilizator.

Riscurile sunt considerabile deoarece PHP reprezintă una dintre principalele tehnologii utilizate pentru dezvoltarea aplicațiilor web. Platforme precum WordPress, Drupal, Joomla, Magento și Open Journal Systems (OJS) utilizează PHP pentru executarea operațiunilor pe server.

Vulnerabilitățile nu sunt determinate de existența unor pluginuri nesigure sau de parole slabe, ci de componente ale interpretorului PHP însuși. Prin urmare, chiar și un site cu aplicația și extensiile actualizate poate rămâne vulnerabil dacă versiunea PHP utilizată nu conține corecțiile necesare.

Prima vulnerabilitate: CVE-2026-109618 – coruperea memoriei

Prima vulnerabilitate este asociată gestionării defectuoase a situațiilor în care PHP depășește limita de memorie disponibilă pentru executarea unei cereri.

În mod normal, PHP utilizează parametrul memory_limit pentru a controla cantitatea de memorie pe care o poate consuma un script. Dacă această limită este depășită, interpretarea scriptului este întreruptă.

Cercetătorii au descoperit însă că, în anumite circumstanțe, întreruperea poate interveni în momentul în care unele structuri interne de date sunt doar parțial inițializate. La eliberarea memoriei, PHP poate interpreta date invalide ca fiind valide, provocând coruperea memoriei.

Un atacator poate exploata această situație prin cereri HTTP construite special, ceea ce poate conduce la executarea de cod arbitrar.

Deosebit de îngrijorător este faptul că, în configurația Apache cu modulul mod_php, cercetătorii au demonstrat posibilitatea declanșării atacului înainte de executarea codului aplicației web.

Vulnerabilitatea poate afecta și alte moduri de execuție PHP, inclusiv PHP-FPM, în anumite condiții.

A doua vulnerabilitate: CVE-2026-109619 – reutilizarea unor stări interne invalide

A doua vulnerabilitate privește gestionarea informațiilor interne păstrate între cererile procesate de același proces PHP.

Pentru eficiență, serverele reutilizează adesea procese PHP pentru tratarea mai multor solicitări succesive. În anumite situații, după apariția unei erori fatale, unele structuri interne pot păstra referințe către zone de memorie care au fost deja eliberate.

Dacă un proces reutilizează ulterior aceste referințe, se poate produce o eroare de tip use-after-free, care poate permite manipularea memoriei și, în anumite condiții, executarea de cod neautorizat.

Această vulnerabilitate demonstrează că mecanismele interne de administrare a cererilor HTTP pot reprezenta o suprafață de atac chiar și atunci când aplicația web nu conține vulnerabilități cunoscute.

Și această problemă poate fi exploatată fără autentificare în configurațiile vulnerabile.

Ce versiuni PHP sunt afectate?

Echipa PHP a publicat patru versiuni corectate, corespunzătoare ramurilor aflate încă în perioada de suport oficial.

Versiunile corectate au fost publicate la 21 octombrie 2026. Pentru distribuțiile Linux care utilizează actualizări de securitate de tip backport, numărul versiunii poate rămâne diferit, chiar dacă vulnerabilitatea a fost remediată. În aceste situații trebuie consultat buletinul distribuitorului.

PHP 8.2 va ajunge la sfârșitul perioadei de suport la 31 decembrie 2026, ceea ce face recomandabilă planificarea migrării către o versiune mai nouă.

Cât de mare este riscul pentru site-urile web?

Principala consecință posibilă a exploatării acestor vulnerabilități este executarea de cod la distanță, cunoscută sub abrevierea RCE (Remote Code Execution).

În funcție de drepturile procesului PHP și de configurația serverului, un atacator ar putea accesa fișierele aplicației, consulta date confidențiale, modifica paginile publicate, instala programe malițioase sau încerca să compromită alte componente ale infrastructurii.

Aceasta nu înseamnă automat că atacatorul dobândește privilegii de administrator asupra întregului server. Accesul obținut depinde de drepturile procesului compromis și de măsurile de izolare aplicate.

Riscul este deosebit de important pentru aplicațiile care prelucrează documente și fișiere încărcate de utilizatori, date personale, informații financiare ori documente confidențiale.

În cazul platformelor editoriale precum OJS, o compromitere a serverului ar putea afecta manuscrisele încă nepublicate, documentele procesului de recenzare, conturile utilizatorilor și integritatea publicațiilor științifice.

La 21 octombrie, CERT-EU a avertizat asupra circulației primelor demonstrații de exploatare și a recomandat corectarea imediată a sistemelor vulnerabile. Existența acestor demonstrații nu înseamnă însă că fiecare server vulnerabil a fost deja compromis.

Cum pot fi eliminate vulnerabilitățile?

1. Actualizarea imediată a PHP

Singura soluție completă confirmată de echipa PHP este instalarea unei versiuni care conține corecțiile de securitate.

Administratorii trebuie să identifice versiunea PHP utilizată efectiv de fiecare site și să instaleze actualizarea corespunzătoare.

În panourile de găzduire precum cPanel, Plesk sau DirectAdmin, versiunea PHP poate fi verificată și, în funcție de configurația furnizorului, modificată din interfața de administrare.

Pe serverele Linux administrate direct, versiunea PHP disponibilă în linia de comandă poate fi verificată prin:

php -v

Totuși, versiunea afișată de această comandă nu este neapărat identică cu cea utilizată de serverul web. Administratorul trebuie să verifice separat versiunea activă pentru fiecare aplicație, precum și eventualele instanțe PHP-FPM sau containere.

După actualizare este necesară repornirea controlată a proceselor PHP relevante, astfel încât codul vulnerabil aflat deja în memorie să nu continue să funcționeze.

În cazul unui serviciu de găzduire partajată, instalarea efectivă a versiunilor corectate poate depinde de furnizor. Simpla selectare a unei ramuri PHP din panoul de control nu garantează existența ultimelor corecții.

2. Aplicarea unor măsuri temporare de reducere a riscului

În situațiile în care actualizarea nu poate fi realizată imediat, dezvoltatorii PHP au recomandat o serie de măsuri temporare. Acestea reduc anumite căi de exploatare, dar nu elimină complet vulnerabilitățile.

Pentru CVE-2026-109618 sunt recomandate, printre altele, limitarea dimensiunilor cererilor HTTP și a fișierelor încărcate, precum și configurarea atentă a consumului de memorie.

Una dintre măsurile temporare propuse este utilizarea:

memory_limit = -1

Această configurație elimină limita de memorie controlată de PHP, evitând anumite condiții care pot declanșa vulnerabilitatea. Nu este însă o configurație care trebuie aplicată fără evaluare, deoarece poate conduce la consum excesiv de memorie și la indisponibilitatea serviciului. Trebuie însoțită de mecanisme adecvate de izolare și limitare a resurselor la nivelul sistemului.

Pentru CVE-2026-109619, echipa PHP recomandă, ca măsură temporară, dezactivarea mecanismului de urmărire a progresului încărcărilor prin sesiune:

session.upload_progress.enabled = 0

În PHP 8.5, dezactivarea funcției fatal_error_backtraces poate reduce suplimentar anumite căi de exploatare.

Aceste configurări trebuie realizate la nivelul adecvat al serverului, înainte de procesarea cererilor, urmate de repornirea proceselor PHP.

Măsurile temporare nu trebuie considerate un substitut pentru actualizare.

3. Verificarea compatibilității aplicațiilor

Trecerea de la o versiune PHP la alta poate produce incompatibilități cu aplicațiile existente.

Pentru WordPress trebuie verificate compatibilitatea temei, a pluginurilor și a extensiilor instalate. Pentru OJS, administratorii trebuie să consulte cerințele versiunii utilizate și compatibilitatea pluginurilor.

În mod ideal, actualizarea trebuie testată într-un mediu separat înainte de aplicarea în producție, cu condiția ca această testare să nu întârzie nejustificat remedierea unui sistem expus public.

O măsură utilă constă în efectuarea unui backup complet al fișierelor și bazei de date înainte de actualizare, urmată de verificarea autentificării, încărcării fișierelor, formularelor și principalelor funcții ale aplicației.

4. Verificarea serverului pentru eventuale compromiteri

Actualizarea PHP împiedică exploatarea vulnerabilităților remediate, dar nu elimină automat programele malițioase instalate anterior.

Administratorii ar trebui să examineze jurnalul cererilor HTTP, erorile PHP, fișierele recent create sau modificate și eventualele procese neobișnuite.

O atenție specială trebuie acordată directoarelor în care utilizatorii pot încărca fișiere și zonelor în care aplicația dispune de drepturi de scriere.

Dacă apar indicii de compromitere, este recomandată izolarea sistemului afectat, conservarea dovezilor și efectuarea unei analize înainte de restaurarea serviciului. Pot fi necesare și schimbarea credențialelor, verificarea integrității aplicației și restaurarea din copii de siguranță de încredere.

5. Consolidarea securității pe termen lung

Pe lângă actualizarea PHP, administratorii ar trebui să adopte o politică permanentă de securitate, bazată pe actualizări regulate, drepturi minime de acces, copii de siguranță și monitorizarea integrității fișierelor.

Utilizarea unui firewall pentru aplicații web, precum Cloudflare WAF sau ModSecurity, poate limita anumite atacuri, dar nu garantează blocarea celor două vulnerabilități.

Pentru serverele care găzduiesc mai multe aplicații este recomandată separarea proceselor și a drepturilor de acces. În acest fel, compromiterea unui site nu conduce neapărat la accesarea celorlalte aplicații găzduite pe același server.

De asemenea, directoarele utilizate exclusiv pentru încărcarea documentelor trebuie configurate astfel încât fișierele încărcate să nu poată fi executate ca scripturi.

Ce trebuie să facă administratorii WordPress și OJS?

Pentru administratorii care utilizează găzduire partajată, remedierea poate fi relativ simplă, dar este importantă verificarea efectivă a versiunii PHP instalate.

Etapele prioritare sunt identificarea versiunii PHP pentru fiecare domeniu și subdomeniu, confirmarea disponibilității versiunii corectate, efectuarea unui backup și aplicarea actualizării.

Dacă versiunea PHP corectată nu este încă disponibilă în panoul de administrare, furnizorului de găzduire trebuie să i se solicite explicit instalarea actualizării sau confirmarea aplicării unei corecții de securitate echivalente.

Pentru OJS, verificarea trebuie extinsă asupra directoarelor de încărcare a manuscriselor, a drepturilor de scriere și a jurnalelor serverului. Pentru WordPress, sunt relevante și directoarele de încărcare media, pluginurile și temele.

Este important de subliniat că dezactivarea temporară a înregistrării utilizatorilor, a formularelor de autentificare sau a trimiterii documentelor poate reduce anumite suprafețe de atac, dar nu remediază vulnerabilitățile din interpretorul PHP.

Un incident care ridică întrebări despre securitatea infrastructurii web

Aceste vulnerabilități au evidențiat și dificultățile asociate întreținerii unui proiect software fundamental pentru infrastructura internetului.

PHP Foundation a recunoscut că primele indicii ale problemei privind administrarea memoriei au apărut încă din 2024. La acel moment, identificarea unei metode concrete de exploatare era dificilă, iar corectarea problemei implica modificări importante ale mecanismelor interne PHP.

În august 2026, noi cercetări au demonstrat posibilitatea exploatării grave a deficienței, accelerând dezvoltarea corecțiilor.

PHP Foundation a recunoscut că întârzierea remedierii a reflectat și probleme structurale ale procesului de securitate, inclusiv resursele limitate disponibile pentru analiza și modificarea componentelor fundamentale ale limbajului.

Organizația a anunțat consolidarea echipei sale de securitate și extinderea colaborării cu cercetători independenți, inclusiv prin utilizarea unor instrumente de analiză asistate de inteligență artificială.

Concluzii

Descoperirea celor două vulnerabilități critice din PHP demonstrează că securitatea aplicațiilor web depinde nu numai de calitatea codului propriu, ci și de securitatea componentelor software pe care acestea sunt construite.

Un site WordPress sau OJS poate utiliza parole puternice, autentificare multifactorială, filtre pentru fișiere și un firewall performant, dar poate rămâne expus unor atacuri grave dacă interpretorul PHP conține vulnerabilități care permit executarea de cod înainte de aplicarea controalelor de securitate ale aplicației.

Actualizările publicate la 21 octombrie 2026 reprezintă, prin urmare, o prioritate imediată pentru administratorii serverelor și furnizorii de servicii de găzduire.

Recomandarea esențială este actualizarea PHP la o versiune corectată, verificarea aplicării efective a acesteia și examinarea sistemelor pentru eventuale semne de compromitere. Măsurile de protecție complementare rămân necesare, dar nu pot înlocui remedierea vulnerabilităților de la nivelul interpretorului.

Surse și referințe

1. PHP Development Team (2026, 21 octombrie). Security advisory: Critical remote code execution vulnerabilities, update now. PHP.net

2. PHP Foundation (2026, 21 octombrie). Today’s PHP Security Release, and How We’re Strengthening PHP Security. PHP Foundation.

3. CERT-EU (2026, 21 octombrie). Critical Vulnerabilities in PHP, Security Advisory 2026-018. CERT-EU.

4. PHP Development Team. Supported Versions. PHP.net.

5. PHP Security Advisory. CVE-2026-109618. GitHub Security Advisory.

6. PHP Security Advisory. CVE-2026-109619. GitHub Security Advisory.