Vulnerabilitate CVE critică în PHP și GitLab: ce înseamnă și ce măsuri au luat adminii site-urilor din România

Pe 21 octombrie 2026, echipele IT din toată lumea au avut o zi agitată. Proiectul PHP a publicat corecții pentru două breșe critice, botezate „PHP2Shell”, iar GitLab a lansat un patch de urgență pentru o vulnerabilitate cu scor maxim. Fiecare vulnerabilitate CVE din acest val are scor critic. Breșele din PHP sunt atât de importante întrucât afectează limbajul care rulează în spatele unei mari părți a internetului, de la bloguri și magazine online până la portaluri guvernamentale.

În România, Directoratul Național de Securitate Cibernetică (DNSC) a emis alerte separate pentru PHP și pentru GitLab. 

În acest articol explicăm ce înseamnă o vulnerabilitate CVE și cum se citește scorul CVSS, ce fac concret aceste breșe, ce urmări au avut în primele zile și ce pași trebuie să urmezi dacă administrezi un server, un site sau o instanță GitLab.

Ce este o vulnerabilitate CVE și ce arată scorul CVSS

O vulnerabilitate CVE este o breșă de securitate cunoscută public, care a primit un identificator unic în catalogul Common Vulnerabilities and Exposures. Formatul e simplu: anul și un număr de ordine, de exemplu CVE-2026-109618. Astfel, producătorii, agențiile și echipele de securitate vorbesc despre aceeași problemă fără confuzii.

CVSS (Common Vulnerability Scoring System) măsoară gravitatea unei vulnerabilități pe o scară de la 0 la 10. Scorurile între 9,0 și 10,0 sunt considerate critice. Calculul ține cont de modul de atac, de nevoia unui cont sau a interacțiunii victimei și de impactul asupra confidențialității, integrității și disponibilității datelor.

Versiunea 3.1 a standardului și versiunea 4.0, lansată în noiembrie 2023, nu dau scoruri direct comparabile. CVSS v4.0 adaugă, printre altele, o metrică pentru condițiile necesare atacului și evaluează separat impactul asupra sistemelor conectate. Practic, un 9,2 în v4.0 și un 10,0 în v3.1 transmit același mesaj: actualizează acum.

Vulnerabilitate PHP critică: ce este PHP2Shell

Cele două breșe, CVE-2026-109618 și CVE-2026-109619, sunt cunoscute împreună sub numele „PHP2Shell”. Ambele pot permite unui atacator neautentificat să execute cod pe server, adică să preia controlul acestuia. Fiecare vulnerabilitate PHP din această pereche se află în nucleul limbajului, nu într-o aplicație sau într-un plugin anume.

Pe scurt:

• CVE-2026-109618, coruperea memoriei la epuizarea ei (OOM). Când PHP rămâne fără memorie, procesarea se oprește brusc, iar unele date interne ale cererii rămân inițializate doar pe jumătate. La curățare, PHP le tratează ca fiind valide, iar atacatorul poate exploata această confuzie.
• CVE-2026-109619, stare globală reziduală. Anumite date interne supraviețuiesc după ce memoria lor a fost eliberată. O cerere ulterioară, procesată de același worker, le poate folosi înainte de resetare, o problemă clasică de tip use-after-free.

Riscul privește orice instalare PHP care servește cereri web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Echipa PHP consideră mod_php cel mai expus, deoarece exploitul demonstrat funcționează înainte să ruleze vreo linie din codul aplicației. Prin urmare, sistemul de autentificare al site-ului nu oprește atacul.

Corecțiile au apărut pe 21 octombrie, la 14:00 UTC, în versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Versiunile 8.1 și mai vechi nu mai primesc actualizări oficiale. Totuși, pentru 7.4, 8.0 și 8.1, echipa PHP a publicat patch-uri minimale în codul sursă.

Amploarea este uriașă. PHP rulează pe aproape 70% dintre site-urile al căror limbaj de server este cunoscut, inclusiv în spatele WordPressului. Palo Alto Networks a identificat peste 22,6 milioane de instanțe expuse online, potențial vulnerabile; cifra nu înseamnă site-uri unice sau breșe confirmate. Breșele au fost descoperite cu ajutorul inteligenței artificiale.

Pe 23 octombrie, echipa PHP a anunțat încă o problemă de execuție de cod, CVE-2026-115560, necorectată de actualizările din 21 octombrie. Aceasta apare doar într-o combinație rară de configurare și cod, iar până la următoarea versiune se recomandă dezactivarea funcției session.upload_progress.

GitLab CVE-2026-110264: o vulnerabilitate CVE cu scor maxim

Tot pe 21 octombrie, GitLab a lansat un patch critic pentru 12 vulnerabilități din edițiile Community (CE) și Enterprise (EE). Cea mai gravă, CVE-2026-110264, a primit scorul maxim, 10,0 în CVSS v3.1.

Problema este o depășire de întreg (integer overflow) apărută la compilarea unei expresii regulate special construite. Prin ea, un utilizator neautentificat poate executa cod arbitrar pe serverul GitLab. Vectorul CVSS explică scorul: atac prin rețea, complexitate redusă, fără cont, fără interacțiune și cu impact care depășește componenta vulnerabilă.

Sunt afectate toate versiunile începând cu 7.0, până la versiunile corectate: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 și 19.5.1. GitLab.com rulează deja versiunea reparată, iar clienții GitLab Dedicated nu trebuie să facă nimic. Acțiunea revine doar celor care își găzduiesc singuri GitLab (instalări self-managed).

De ce contează atât de mult? Un server GitLab păstrează codul sursă, pipeline-urile CI/CD și, adesea, secrete precum chei API sau date de acces pentru deployment. Compromiterea lui poate deschide drumul către întreaga infrastructură și chiar către clienți, printr-un atac asupra lanțului de livrare a software-ului.

La momentul lansării nu exista un exploit public sau atacuri confirmate. Totuși, precedentul e îngrijorător: pe 12 octombrie, GitLab corectase CVE-2026-97229, o breșă similară în compilatorul de expresii regulate din CI/CD, tot cu scor 10,0. Pentru aceasta a apărut un exploit public în doar câteva zile. GitLab a publicat și două reguli de detecție, care urmăresc căderile motorului de expresii regulate Onigmo și rafalele de erori la randarea fișierelor Org mode.

Ce urmări au avut vulnerabilitățile

PHP2Shell a trecut foarte repede de la avertisment la tentative reale de atac. Amazon a detectat o primă încercare de exploatare pe 17 octombrie, cu patru zile înainte de anunțul public. După publicarea patch-urilor, exploit-urile au apărut în câteva ore, iar Amazon descrie acum tentative de exploatare pe scară largă.

Reacția autorităților a fost rapidă. Agenții de securitate cibernetică din SUA, Marea Britanie, UE, Canada, Australia și Japonia au cerut actualizarea imediată a site-urilor importante. FBI și NSA au recomandat chiar scoaterea offline a sistemelor care nu pot fi actualizate rapid. Site-uri din Finlanda, Olanda, Belgia și Franța au fost oprite sau au funcționat parțial, iar în Japonia, Nomura și Mitsubishi UFJ au suspendat temporar unele servicii online.

Ce au făcut administratorii de site-uri din România

DNSC a avertizat că „orice server PHP neactualizat și expus în Internet trebuie considerat la risc ridicat de compromitere”. Potrivit Observator News, directoratul a notificat aproximativ 16.000 de entități. În primele zile, administratorii din mai multe domenii au ales între actualizarea rapidă și oprirea preventivă:

1. Administrație publică. Site-ul Poliției Române și paginile inspectoratelor județene au fost temporar indisponibile pentru mentenanță și actualizări de securitate. Primăria Sectorului 4 și-a suspendat temporar platformele electronice, iar Primăria Tulcea a restricționat accesul la portal pentru protejarea datelor cetățenilor.
2. Educație. Universitatea Babeș-Bolyai din Cluj-Napoca și Universitatea de Vest din Timișoara au suspendat preventiv anumite servicii și aplicații online.
3. Energie. Un mare furnizor de gaze naturale și-a închis preventiv site-ul pentru actualizări de securitate.
4. Vânzări online. Un site de vânzare a biletelor la cinema a fost închis temporar pentru actualizări urgente de securitate.
5. Hosting. cyber_Folks a aplicat corecțiile pentru toate versiunile PHP de pe serverele sale, fără vreo acțiune din partea clienților de shared hosting. Clienții cu VPS fără management răspund însă singuri de actualizare.
6. Dezvoltare software. Zitec a activat reguli WAF înaintea patch-urilor oficiale și a reconstruit imaginile proiectelor în 15 minute de la publicarea versiunilor corectate. Compania nu raportase atacuri confirmate la data comunicatului.

Remedierea avansează însă inegal. O analiză a ValidSoftware, publicată pe 26 octombrie, arată că majoritatea instituțiilor publice care afișează o versiune PHP corectabilă au actualizat-o. Într-un eșantion de site-uri private .ro, mai puțin de jumătate erau actualizate. În plus, un număr „deloc neglijabil” de instituții rulează încă PHP 8.1 sau mai vechi, fără suport oficial.

Un detaliu important pentru proprietarii de site-uri: actualizarea temei sau a pluginurilor nu rezolvă o vulnerabilitate PHP din nucleul limbajului. Trebuie actualizat chiar PHP-ul, de către tine sau de furnizorul de hosting. Pentru vizitatori, informațiile disponibile nu indică faptul că simpla accesare a unui site afectat le-ar infecta dispozitivul.

Cum să răspunzi la o vulnerabilitate CVE critică: pași concreți pentru administratorii de site-uri

• Fă inventarul. Identifică toate serverele, containerele și aplicațiile terțe care rulează PHP sau GitLab, inclusiv echipamentele care au PHP încorporat. Verifică versiunea cu php -v, dar și pe cea folosită efectiv de PHP-FPM sau de Apache.
• Actualizează imediat. PHP trebuie adus la 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau la pachetele corectate de distribuția ta. GitLab self-managed trebuie adus la una dintre versiunile corectate. După update, repornește toți workerii PHP-FPM.
• Prioritizează sistemele expuse la internet. Dacă nu le poți actualiza imediat, izolează-le de rețeaua publică până la aplicarea patch-ului.
• Folosește măsurile temporare doar ca soluție de avarie. Pentru PHP, setează session.upload_progress.enabled=0 în php.ini sau în pool-ul FPM, nu prin ini_set() ori .user.ini, apoi repornește workerii. Pe PHP 8.5 adaugă și fatal_error_backtraces=0. Echipa PHP subliniază că doar actualizarea rezolvă complet problema.
• Caută semne de compromitere începând cu 17 octombrie. Analizează jurnalele serverului web și ale aplicației, procesele, fișierele, conturile noi și conexiunile de ieșire neobișnuite. Pentru GitLab, folosește regulile de detecție publicate de producător.
• Planifică upgrade-urile. Upgrade-ul GitLab include migrări de bază de date, deci instanțele cu un singur nod vor avea o întrerupere în timpul actualizării. PHP 8.2 nu mai primește corecții de securitate după 31 decembrie 2026, iar 8.1 și versiunile mai vechi nu le mai primesc deja.

Organizațiile cu inventar clar, proceduri de actualizare și monitorizare activă au reacționat în aceeași zi. Lecția e valabilă și pentru developeri: o aplicație sigură depinde de configurarea serverului, de dependențe și de actualizări, nu doar de codul scris.

La NewTech Academy pregătim specialiști în dezvoltare software și securitate cibernetică pe scenarii reale, ca acesta. Dacă vrei să înveți să previi, să detectezi și să răspunzi la incidente, descoperă cursul de IT și securitate cibernetică.

Concluzie: securitatea se învață, nu se improvizează

Incidentele din octombrie arată cât de mult s-a scurtat fereastra dintre anunț și atac. PHP2Shell arată că o vulnerabilitate CVE critică poate fi exploatată chiar înainte de patch. Amazon observă că analiza asistată de inteligența artificială transformă tot mai repede un patch într-un exploit funcțional, așa că timpul de reacție se măsoară acum în ore, nu în săptămâni.

Întrebări frecvente despre această vulnerabilitate CVE