Vulnerabilități critice în PHP: ziua în care guvernele și-au închis site-urile și ce aveți de făcut

Două vulnerabilități critice în PHP, CVE-2026-109618 și CVE-2026-109619, au închis pe 21 octombrie 2026 site-urile guvernului finlandez, ale prefecturilor din Franța, ale parlamentului olandez și ale guvernului ceh, au scos temporar din funcțiune sisteme ale Wikipedia și l-au făcut pe premierul Japoniei să ceară public oprirea site-urilor care nu pot fi actualizate. Fiecare defect are scorul 9,2 din 10 pe scala CVSS v4.0 și permite execuția de cod pe server fără autentificare. Singura rezolvare completă este actualizarea la PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, publicate în aceeași zi, iar DNSC a emis alerta pentru România în dimineața aceleiași zile, cu ore înaintea corecțiilor. Acest articol pune cap la cap ce au spus agențiile din SUA, Uniunea Europeană, Marea Britanie, Olanda, Germania, Canada și Japonia, pentru ca dumneavoastră să știți exact ce aveți de făcut.

Cum s-a desfășurat ziua de 21 octombrie 2026?

Ca o evacuare controlată: în mai puțin de 24 de ore, de la anunțul preliminar al echipei PHP până la ora corecțiilor, guverne și companii din trei continente au ales să își oprească site-urile decât să le lase expuse. Cronologia de mai jos este reconstituită din comunicatele oficiale și din avizul PHP; orele sunt date așa cum le-au publicat sursele, cu echivalentul pentru România.

Ce sunt CVE-2026-109618 și CVE-2026-109619?

Sunt două defecte de memorie din nucleul interpretorului PHP, nu din WordPress, Drupal sau dintr-un plugin, descrise de echipa PHP în avizul de securitate de pe php.net. CVE-2026-109618 apare când o eroare de memorie insuficientă întrerupe PHP în timp ce datele interne ale cererii sunt doar parțial inițializate; curățarea de la final tratează datele invalide ca valide. CVE-2026-109619 ține de starea globală învechită: informații ale unei cereri supraviețuiesc după ce memoria lor a fost eliberată, iar cererea următoare, procesată de același worker, le refolosește înainte de reinițializare. Cyber Centre din Canada le încadrează pe amândouă la categoria use-after-free (CWE-416).

Pentru cine nu scrie cod: un atacator trimite cereri construite special, cel mai adesea un simplu POST, cum notează NCSC din Olanda, forțează una dintre cele două situații și ajunge să ruleze propriul cod cu drepturile procesului web. Fără parolă și fără cont. Wiz a demonstrat atacul fără autentificare pe imaginile curente de WordPress, Drupal și Joomla, plus o variantă care nu execută cod, dar citește memoria procesului PHP: parole, token-uri, chei API. Avizele tehnice sunt pe GitHub, GHSA-w8hw-w9fx-j79w și GHSA-6wmf-4rv5-p3rp. Pentru termenii tehnici, dicționarul de securitate cibernetică de pe site are explicații scurte.

Cine a descoperit vulnerabilitățile și de ce contează că le-a găsit un model de IA?

Wiz Research, cu patru cercetători (Sagi Tzadik, Shir Tamari, Nir Ohfeld, Tomer Schwartz) și trei modele de inteligență artificială, Wiz Atlas, Gemini 4 Argon și GPT-5.6 Sol, conform raportului publicat de Wiz pe 21 octombrie. Primul defect a fost găsit pe 19 august, a doua zi era confirmată execuția de cod pe Drupal, pe 21 august pe WordPress, iar pe 24 august ambele au fost raportate echipei PHP. Separat, compania Calif a găsit unul dintre defecte cu modelul GPT-5.6 Sol al OpenAI, iar Cloudflare mai numește și Quarkslab printre cei care au dezvăluit problema. Wiz le-a botezat împreună „PHP2Shell” și susține că fiecare versiune PHP din ultimul deceniu, până la 5.4, este afectată de cel puțin una; echipa PHP nu a confirmat această afirmație, iar avizul ei vorbește de ramurile 8.2-8.5.

De ce contează metoda: OpenAI a scris că aceleași capacități „pot ajuta atacatorii să dezvolte rapid instrumente ofensive și exploit-uri”, iar cercetătorul Nicholas Weaver a formulat-o și mai scurt pentru Cybersecurity Dive: un lucru la care sistemele de IA sunt foarte bune este să transforme un patch într-un exploit. Cu alte cuvinte, fereastra dintre publicarea corecției și apariția atacurilor automate se micșorează. În opinia mea, acesta este motivul real pentru care atâtea guverne au preferat să stingă lumina pentru câteva ore în loc să aștepte.

Ce au recomandat NSA, FBI, CISA și Casa Albă?

Să actualizați imediat și, dacă nu puteți, să scoateți sistemul de pe internet până când puteți. NSA a publicat pe 21 octombrie, de la Fort Meade, un comunicat în care cere organizațiilor să fie pregătite pentru actualizare și, dacă aceasta nu este posibilă imediat, să țină sistemul afectat offline până la remedierea completă. Fraza care mi-a rămas în minte: „Aceste vulnerabilități oferă adesea o cale directă către sistemul de fișiere sau baza de date a serverului.” NSA a anunțat și îndrumări suplimentare.

Divizia Cyber a FBI a avertizat în aceeași zi, pe X, că atacatorii pot executa cod de la distanță și pot compromite informații sensibile și rețele. CISA a publicat alerta „Critical Vulnerabilities in PHP Require Immediate Patching”, iar Casa Albă a precizat că guvernul american a aflat de vulnerabilități pe 16 octombrie și că „urmărește și coordonează cu agențiile federale și cu laboratoarele de IA de top pentru a grăbi publicarea remedierii”, potrivit Cybersecurity Dive. OpenAI a confirmat că a coordonat corecția cu CISA și cu Biroul Directorului Național pentru Cibernetică.

Ce au spus autoritățile europene: CERT-EU, NCSC Olanda, NCSC Marea Britanie, BSI?

Au spus același lucru, cu accente diferite, și tabelul de mai jos le pune față în față. Avizul CERT-EU 2026-018, cel citat de DNSC, cere actualizarea imediată sau izolarea aplicațiilor expuse pe internet, notează că dovezi de concept circulă deja public și trimite la un inventar întreținut de NCSC din Olanda pe GitHub, NCSC-NL/php2shell, cu produsele comerciale care încorporează PHP. Olandezii au fost cei mai direcți: orice sistem care conține PHP și este accesibil de pe internet este prezumat vulnerabil până la actualizare, iar NCSC-NL și-a închis propriul site ca măsură de precauție, lucru anunțat pe site-ul guvernului olandez.

Care dintre alertele europene este cea mai utilă pentru un administrator?

Alerta canadiană, cu lista de jurnale, și cea britanică, cu ordinea pașilor. Lista completă a celor opt pași britanici este în alerta NCSC UK, iar alerta canadiană, AL26-026, este cea mai utilă pentru cine trebuie să verifice efectiv un server, pentru că spune ce jurnale să deschideți.

Care guverne și companii și-au închis site-urile?

Finlanda, Olanda, Franța, Cehia, landul german Baden-Württemberg, orașul Mainz, două spitale universitare germane, Wikimedia și mai multe platforme japoneze, toate ca măsură preventivă, nu ca răspuns la un atac confirmat. În Finlanda, Valtori a început să blocheze traficul public la 12:45 și a precizat că acțiunea este preventivă; au fost afectate site-ul Institutului Național de Cadastru, servicii ale Universității din Helsinki, ale postului public Yle și ale centrului expozițional Messukeskus, conform Helsinki Times. Centrul finlandez de securitate cibernetică nu avea dovezi de exploatare.

În Olanda au fost oprite MijnOverheid.nl și DigiD, site-ul Camerei Reprezentanților, site-ul NCSC, site-ul Autorității pentru Protecția Datelor, site-ul și aplicația RTL, Tweakers, sistemul de ședințe Notubiz folosit de circa o sută de municipalități, sisteme din învățământul superior și de la agenția de presă ANP, potrivit NOS. În Franța, Ministerul de Interne a scos din funcțiune site-urile prefecturilor până la apariția corecției; în Cehia, guvernul și-a oprit site-ul la ora 20:00 (ora României) după avertismentul autorității naționale, conform Radio România Actualități.

Ce s-a întâmplat în Germania, la Wikipedia și în Japonia?

Aceeași alegere, oprirea preventivă. În Germania, landul Baden-Württemberg a oprit site-urile ministerelor și ale prefecturilor regionale pentru „protecția preventivă a infrastructurii”, spitalele universitare din Heidelberg și Mannheim și-au închis site-urile precizând că activitatea medicală nu este afectată, iar orașul Mainz a dezactivat mainz.de și mai multe servicii online, conform Security Insider. Wikimedia Foundation a confirmat pentru Mashable că a scos temporar din funcțiune mai multe sisteme în timp ce aplica corecțiile; Downdetector număra peste 3.000 de sesizări din SUA la ora 10:51 ET. În Japonia, premierul Sanae Takaichi a postat pe X, la 21:55 ora Tokyo, că oprirea temporară a site-ului este o cale eficientă de reducere a riscului pentru cine nu poate instala rapid actualizarea, iar pixiv, DMM, niconico și BASE au intrat în mentenanță de urgență, conform tech-ish.

Ce spune alerta DNSC și ce s-a întâmplat în România?

Alerta „DNSC ALERT v2026.10.21”, publicată pe dnsc.ro în dimineața de 21 octombrie, înainte de apariția corecțiilor, este mai concretă decât majoritatea alertelor străine și merită citită integral, inclusiv în varianta PDF atașată. Ea separă ce confirmase PHP (două vulnerabilități, scor 9,2, publicare la 14:00 UTC) de ce venea din scurgeri neconfirmate (identificatorii CVE, scenariul de exploatare, lipsa înregistrărilor în NVD și pe CVE.org la acea oră) și face o observație pe care o subscriu: din experiențele anterioare, vulnerabilitățile critice se exploatează în mai puțin de 24 de ore de la publicarea detaliilor tehnice.

Înainte de corecții, DNSC a cerut inventarul tuturor sistemelor cu PHP, inclusiv soluțiile furnizorilor, serverele de test și aplicațiile vechi, cu versiunea, sursa pachetelor și expunerea la internet pentru fiecare; un responsabil desemnat pentru fiecare instalare; dezactivarea session upload progress (în PHP-FPM prin php_admin_flag la nivel de pool); blocarea cererilor multipart/form-data la nivelul serverului web pentru aplicațiile fără încărcări de fișiere; izolarea temporară a aplicațiilor critice și oprirea celor de test. Două avertismente din alertă le-aș lipi pe ușa oricărui departament IT: un WAF ajută numai dacă serverul de origine nu poate fi accesat direct, ocolind filtrarea, iar file_uploads=Off, modul de mentenanță, pluginurile de securitate și verificările de autentificare din aplicație nu sunt protecții, pentru că intervin după ce PHP a procesat deja cererea.

Ce cere DNSC după publicarea corecțiilor?

Verificarea buletinelor distribuțiilor Linux (o corecție poate veni într-un pachet fără schimbarea numărului de versiune PHP afișat), repornirea PHP-FPM și a proceselor de lungă durată, reconstruirea imaginilor de containere și renunțarea la măsurile temporare numai după confirmarea aplicării corecției. Pentru PHP 8.1 și mai vechi, recomandarea este migrarea cât mai rapidă la o versiune între 8.2 și 8.5. Concluzia juridică, citată din Legea nr. 58/2023, art. 5 lit. a): răspunderea pentru securitatea cibernetică a unui sistem revine persoanei fizice sau juridice care îl deține, îl organizează, îl administrează sau îl utilizează. Cu alte cuvinte, nu furnizorului de găzduire, ci dumneavoastră.

A oprit vreo instituție din România un site din cauza PHP?

Nicio instituție din România nu a anunțat public că și-a oprit site-ul din cauza PHP. Singura coincidență de calendar pe care am găsit-o: Primăria Sectorului 4 a anunțat pe 21 octombrie, la 17:46, prin Agerpres, că platformele de taxe, evidența persoanelor, registratură și urbanism sunt în mentenanță până joi dimineață, „absolut necesară pentru întreținerea conformă” a sistemelor. Comunicatul nu menționează PHP, securitatea sau DNSC, așa că nu trag nicio concluzie din el; îl notez pentru că ora și durata se suprapun exact peste fereastra în care guvernele europene făceau același lucru și spuneau de ce.

Ce versiuni PHP repară problema și cine este expus?

Toate instalațiile PHP care servesc cereri web, conform avizului PHP: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed, iar riscul cel mai mare este la mod_php, unde există un exploit demonstrat în care o cerere neautentificată declanșează atacul înainte ca orice linie din aplicație să ruleze. Palo Alto Networks numără peste 22,6 milioane de instanțe PHP expuse pe internet, iar Cisco estimează, potrivit Cybersecurity Dive, că aproximativ jumătate dintre instanțele expuse rulează versiuni prea vechi ca să primească corecțiile. W3Techs atribuie PHP circa 70% dintre site-urile al căror limbaj poate fi identificat.

Distribuțiile Linux și furnizorii LTS au primit corecțiile în avans, deci pachetele vin de la furnizorul sistemului de operare. Depozitul comunitar rpms.remirepo.net nu a avut actualizări în ziua publicării, iar echipa PHP a cerut explicit trecerea la pachetele distribuției. După instalare, reporniți toți workerii PHP; un proces vechi rămas în memorie rulează în continuare codul vulnerabil.

Se exploatează deja vulnerabilitățile?

Depinde pe cine întrebați, și tocmai acest dezacord merită reținut. Cloudflare a scris pe blogul propriu că a observat trafic de atac împotriva clienților săi și atacatori care mutau sarcina utilă ca să ocolească regulile, reguli active implicit din 21 octombrie, 03:02 UTC, inclusiv pe planul gratuit, cu precizarea că protecția este temporară și nu înlocuiește actualizarea. Patchstack, o companie de securitate pentru WordPress, a anunțat la 07:34 UTC „multiple incidente de exploatare activă confirmate”. De cealaltă parte, Jake Knott de la watchTowr spunea pentru Cybersecurity Dive că, până la acel moment, nimeni nu reușise, adăugând că nu se așteaptă să dureze, iar NCSC-NL, NCSC-FI și Cyber Centre Canada declarau că nu au observat exploatare activă la momentul publicării alertelor.

Sansec a semnalat o captură de ecran cu un instrument numit „PHP2Shell”, cu autor și funcție neconfirmate, iar Huntress un videoclip publicat și retras rapid. Ce reiese din toate acestea: tentative există, succese confirmate public nu existau în seara de 21 octombrie, iar toată lumea se aștepta ca situația să se schimbe în câteva zile. Dacă citiți acest articol la o săptămână după publicare, presupuneți că s-a schimbat.

Ce faceți dacă nu puteți actualiza chiar acum?

Reduceți expunerea și decideți dacă sistemul merită ținut online. Echipa PHP recomandă pentru CVE-2026-109618 memory_limit=-1 setat într-un mod pe care aplicațiile nu îl pot suprascrie (php_admin_value în pool-ul FPM sau în configurația Apache), post_max_size mic (8M fără încărcări de fișiere, 32M cu încărcări, cu upload_max_filesize sub el) și limite la nivel de server web sau proxy pentru dimensiunea cererii, numărul de câmpuri și adâncimea structurilor. Pentru CVE-2026-109619: session.upload_progress.enabled=0 cu repornirea tuturor workerilor, din php.ini sau din configurația pool-ului, nu prin ini_set() și nu din .user.ini, iar pe PHP 8.5 și fatal_error_backtraces=0.

Trei avertismente oficiale vin peste această listă. PHP însăși spune că măsurile nu fac o instalație neactualizată sigură. NCSC din Olanda merge mai departe: tentativele de exploatare împotriva acestor măsuri pot provoca refuz de serviciu, deci site-ul poate cădea oricum. DNSC adaugă blocarea cererilor multipart/form-data la nivelul serverului web pentru aplicațiile fără încărcări de fișiere și precizează că un WAF protejează numai dacă serverul de origine nu poate fi accesat direct. De aici și recomandarea comună NSA, NCSC UK, CERT-EU și a premierului japonez: dacă nu puteți actualiza în ore, nu în zile, scoateți sistemul de pe internet. Dacă trebuie să alegeți între a configura atent aceste limite și a actualiza, actualizați; configurarea cere cunoașterea fiecărui pool, actualizarea cere un backup și o fereastră de mentenanță.

Cum verificați jurnalele pentru tentative de exploatare?

Pornind de la lista de indicatori din alerta DNSC, completată cu cele ale Wiz și Cyber Centre Canada. DNSC fixează ora de la care verificați: 20 octombrie 2026, 15:00 UTC, momentul scurgerii detaliilor, și enumeră ce căutați: cereri multipart neobișnuite, erori ale proceselor PHP, fișiere noi sau modificate în directoarele web, modificări ale fișierelor .user.ini sau ale setării auto_prepend_file, sarcini programate ori chei SSH nou introduse, procese de tip shell sau utilitare de descărcare lansate de PHP și conturi noi de administrator în aplicații. Wiz adaugă răspunsurile HTTP 500 repetate, cookie-urile PHPSESSID neobișnuit de mari sau malformate și workerii PHP care se opresc și repornesc fără explicație; Canada, jurnalele de autentificare și de endpoint și conexiunile de ieșire neașteptate.

Echipa PHP cere activarea temporară a jurnalizării complete (log_errors, error_log, error_reporting=E_ALL) și avertizează că lipsa intrărilor din jurnal nu dovedește că sunteți în siguranță. Dacă găsiți indicii, procedura DNSC este cea corectă: izolați serverul, păstrați jurnalele și celelalte dovezi, reinstalați sistemul din surse de încredere și schimbați toate parolele, cheile și secretele la care procesul PHP putea avea acces. Nu curățați întâi și investigați după; echipa de răspuns, internă sau externă, are nevoie de dovezi intacte. Cine se ocupă de asta într-o organizație am descris în articolul despre ce este un CSIRT.

Ce înseamnă alerta pentru o companie cu „doar un site de prezentare”?

Înseamnă că are un server PHP expus pe internet, exact ca parlamentul olandez. Site-ul apsap.ro rulează pe WordPress, deci pe PHP, așa că întrebările de mai jos ni le-am pus și noi pe 21 octombrie: ce versiune de PHP rulează fiecare site, când a fost instalată versiunea corectată, dacă workerii au fost reporniți după instalare. Răspunsul „avem actualizări automate” nu este un răspuns; Wordfence a avertizat explicit că actualizările automate ale WordPress nu aplică această corecție, pentru că PHP este întreținut la nivel de server, nu de aplicație. Cereți versiunea exactă, în scris.

Pentru entitățile esențiale și importante din OUG nr. 155/2024, transpunerea Directivei NIS2, o exploatare reușită poate fi incident semnificativ, cu avertizare timpurie către DNSC în 24 de ore și notificare în 72 de ore de la constatare. Dovada verificărilor de mai sus face parte din măsurile de management al riscului pe care organele de conducere le aprobă și le supraveghează. Despre sancțiuni am scris în analiza amenzilor prevăzute de OUG nr. 155/2024, iar prima amendă aplicată de DNSC pe acest temei arată că termenele se aplică.

Unde învățați să gestionați astfel de alerte, nu doar să le citiți?

La Centrul de Formare APSAP, în cele două programe autorizate de Directoratul Național de Securitate Cibernetică. Cursul Auditor Securitate Cibernetică, autorizat DNSC, cu Cătălin Opran și Sorin Mureșan, vă învață să verificați dacă măsurile există și funcționează: inventarul versiunilor, politica de actualizare, dovezile pe care le cereți furnizorilor. Cursul Membri CSIRT, cu Crina Negoescu și Cătălin Opran, acoperă partea a doua a alertei: triajul jurnalelor, răspunsul la incident și raportarea. Ambele se încheie cu examen în fața unei comisii DNSC și cu diplomă emisă de DNSC; calendarul și tariful sunt pe pagina fiecărui curs.

Dacă vreți să vedeți întâi cum lucrează Centrul de Formare APSAP, pagina De ce Centrul de Formare APSAP listează 12 lucruri pe care le puteți verifica înainte de înscriere, iar ghidul despre cursuri acreditate sau autorizate explică diferența dintre cele două cuvinte. Pentru un program de formare pentru echipa dumneavoastră, scrieți-ne la secretariat; echipa Centrului de Formare APSAP răspunde în aceeași zi lucrătoare.

Pe ce surse se bazează acest articol?

Pe alerta „DNSC ALERT v2026.10.21 Vulnerabilități critice în PHP” din 21 octombrie 2026, în forma publicată pe site și în PDF-ul atașat, și pe documentele oficiale citate în text: avizul de securitate PHP și anunțurile versiunilor 8.5.12, 8.4.27, 8.3.36 și 8.2.35, avizele GHSA de pe GitHub, avizul CERT-EU 2026-018, comunicatul NSA, alerta CISA, alerta NCSC UK, comunicatul NCSC-NL de pe rijksoverheid.nl, alerta AL26-026 a Cyber Centre Canada, raportul Wiz Research și nota tehnică a Cloudflare. Închiderile de site-uri sunt preluate din Helsinki Times, NOS, Security Insider, Radio România Actualități, Agerpres, tech-ish și din relatările Mashable și Downdetector despre Wikimedia; declarațiile Casei Albe, OpenAI, watchTowr și Cisco, din Cybersecurity Dive. Datele tehnice vin exclusiv din avizul PHP; interpretările despre jurnale, furnizori de găzduire și Primăria Sectorului 4 sunt ale mele. Celelalte analize pe care le semnez sunt pe pagina de autor Mirela Brașoveanu.

Întrebări frecvente despre vulnerabilitățile critice în PHP din 21 octombrie 2026

Ce sunt vulnerabilitățile critice în PHP semnalate de DNSC pe 21 octombrie 2026?

Sunt două defecte de memorie din nucleul PHP, CVE-2026-109618 și CVE-2026-109619, fiecare cu scor CVSS v4.0 de 9,2 din 10, care permit unui atacator să execute cod pe server fără autentificare, de regulă printr-o simplă cerere POST. Prima pornește de la o eroare de memorie insuficientă care lasă datele cererii parțial inițializate, a doua de la informații ale unei cereri care supraviețuiesc în memorie și sunt refolosite de cererea următoare. Au fost descoperite de Wiz Research și Calif cu ajutorul unor modele de IA, raportate echipei PHP pe 24 august, corectate pe 21 octombrie 2026 și semnalate în aceeași zi de DNSC, pe baza avizului CERT-EU 2026-018.

Ce versiune de PHP trebuie să instalați ca să fiți protejat?

Una dintre versiunile 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, în funcție de ramura pe care o folosiți. Pe servere Linux, pachetele actualizate vin de la distribuție sau de la furnizorul LTS, care au primit corecțiile în avans. Pentru PHP 8.1, 8.0 și 7.4, proiectul PHP nu mai publică versiuni, dar echipa de securitate a pus la dispoziție backport-uri minimale pe sursă; dacă dumneavoastră rulați încă una dintre aceste ramuri, trecerea la o ramură suportată este singura soluție de durată, iar DNSC încadrează aceste sisteme expuse pe internet la risc ridicat. După instalare, reporniți toți workerii PHP, altfel procesele vechi rămân în memorie cu codul vulnerabil.

De ce și-au închis guvernele site-urile în loc să aștepte corecția?

Pentru că detaliile tehnice au apărut public pe 20 octombrie, cu aproape o zi înaintea corecției, iar măsurile temporare recomandate de PHP nu blochează toate variantele de atac. NSA, NCSC din Marea Britanie, CERT-EU și premierul Japoniei au recomandat explicit scoaterea de pe internet a sistemelor care nu pot fi actualizate rapid. Finlanda, Olanda, Franța, Cehia și landul Baden-Württemberg au aplicat exact această recomandare, toate precizând că este o măsură preventivă, nu răspunsul la un atac confirmat. Pentru dumneavoastră, logica este aceeași: câteva ore de indisponibilitate costă mai puțin decât un server compromis.

Site-ul rulează pe WordPress la un furnizor de găzduire. Ce aveți de făcut?

Cereți furnizorului, în scris, versiunea exactă de PHP pe care rulează site-ul dumneavoastră și data la care a fost instalată versiunea corectată. Dacă aveți acces la panoul de administrare al găzduirii, puteți selecta singur ramura de PHP, iar raportul de stare din WordPress vă arată versiunea pe care rulează efectiv site-ul. Nu vă mulțumiți cu formularea „avem actualizări automate”: Wordfence a avertizat că actualizările automate ale WordPress nu aplică această corecție, care se face la nivel de server, iar DNSC precizează că pluginurile de securitate și modul de mentenanță nu sunt protecții. Dacă furnizorul rulează încă PHP 8.1 sau mai vechi, mutați site-ul pe o ramură suportată sau schimbați furnizorul.

Puteți reduce riscul fără să actualizați PHP?

Parțial și temporar. Echipa PHP recomandă memory_limit=-1 setat prin php_admin_value, un post_max_size mic (8M fără încărcări de fișiere, 32M cu încărcări), session.upload_progress.enabled=0 cu repornirea workerilor și, pe PHP 8.5, fatal_error_backtraces=0. Aceste setări închid căile de atac confirmate, nu toate variantele posibile, iar PHP spune explicit că nu fac o instalație neactualizată sigură. NCSC din Olanda adaugă că tentativele de exploatare împotriva acestor setări pot provoca refuz de serviciu. Tratați-le ca pe o măsură pentru orele de până la fereastra de mentenanță, nu ca pe o alternativă la actualizare sau la oprirea temporară a sistemului.

Cum aflați dacă site-ul a fost deja atacat?

Începeți cu jurnalele PHP-FPM și ale serverului web de la 20 octombrie 2026, ora 15:00 UTC, momentul fixat de DNSC ca început al ferestrei de risc, și căutați indicatorii din alertă: cereri multipart neobișnuite, erori ale proceselor PHP, fișiere noi sau modificate în directoarele web, modificări ale .user.ini sau ale setării auto_prepend_file, sarcini programate ori chei SSH noi, procese shell sau utilitare de descărcare lansate de PHP, conturi noi de administrator în aplicații. Wiz adaugă răspunsurile HTTP 500 repetate și cookie-urile PHPSESSID malformate. Dacă găsiți indicii, procedura DNSC este: izolați serverul, păstrați jurnalele și dovezile, reinstalați din surse de încredere și schimbați parolele, cheile și secretele la care procesul PHP avea acces.

Trebuie să raportați la DNSC?

Simpla existență a vulnerabilității pe serverele dumneavoastră nu se raportează. Dacă însă sunteți entitate esențială sau importantă în sensul OUG nr. 155/2024 și constatați că una dintre cele două vulnerabilități a fost exploatată, incidentul poate fi unul semnificativ, cu avertizare timpurie către DNSC în 24 de ore de la constatare și notificare în 72 de ore. Pentru companiile care nu intră sub incidența ordonanței, raportarea nu este obligatorie, dar DNSC primește sesizări la numărul 1911 și prin platforma pnrisc.dnsc.ro, iar alerta amintește că răspunderea pentru securitatea unui sistem revine, potrivit Legii nr. 58/2023, art. 5 lit. a), celui care îl deține, îl organizează, îl administrează sau îl utilizează.

Ce curs vă pregătește să gestionați astfel de alerte?

La Centrul de Formare APSAP, cursul Auditor Securitate Cibernetică, autorizat DNSC, vă învață să verificați dacă politica de actualizare, inventarul versiunilor și dovezile cerute furnizorilor există și funcționează în organizația dumneavoastră. Cursul Membri CSIRT, tot autorizat DNSC, acoperă triajul jurnalelor, răspunsul la incident și notificarea către autorități, adică exact ce au cerut DNSC, CERT-EU și NCSC pe 21 octombrie 2026. Ambele programe se încheie cu examen susținut în fața unei comisii DNSC și cu diplomă emisă de DNSC, iar calendarul și tariful sunt publicate pe pagina fiecărui curs.