Cloudflare a activat automat protecții WAF pentru vulnerabilitățile php2shell din PHP, cu aproximativ nouă ore înainte de divulgarea publică, pentru toate planurile, inclusiv Free. Regulile corelează requestul cu răspunsul originii. WAF-ul nu înlocuiește patch-ul: administratorii trebuie să actualizeze PHP, altfel expunerea rămâne.

Două vulnerabilități în runtime-ul PHP, trackuite drept CVE-2026-109618 și CVE-2026-109619, au intrat pe 21 octombrie 2026 în atenția publică sub numele de php2shell. Sursa este anunțul Cloudflare (blog.cloudflare.com), care documentează atât defectele, cât și modul în care au fost livrate mitigările. Nu este o știre despre o companie care își laudă produsul. Este un studiu de caz despre cum arată un răspuns de infrastructură la o vulnerabilitate de runtime, înainte ca exploit-urile să ajungă în mâinile majorității atacatorilor.

Ce trebuie reținut din start: problema nu se rezolvă din codul site-ului, din plugin-uri sau din tema WordPress. Se rezolvă din versiunea de PHP de pe server.

Ce sunt, de fapt, vulnerabilitățile php2shell

Ambele defecte țin de modul în care PHP gestionează memoria atunci când ceva merge prost în timpul procesării unui request HTTP. În mod normal, PHP alocă memorie pentru datele necesare, le procesează, apoi eliberează memoria. Când procesarea se întrerupe brusc, de exemplu pentru că s-a atins limita de memorie, curățenia nu se mai face corect. Aici apar cele două scenarii distincte.

La CVE-2026-109618, PHP rămâne fără memorie și întrerupe lucrul înainte ca anumite structuri interne să fie complet inițializate. La curățare, procesul folosește date neterminate ca și cum ar fi valide. La CVE-2026-109619, o eroare fatală lasă PHP cu referințe către memorie eliberată la finalul requestului. Când același proces PHP servește un request ulterior, poate urma acele referințe vechi și poate accesa memorie invalidă.

Impactul posibil, conform sursei, acoperă trei direcții: blocarea serviciului (denial of service), execuția de cod la distanță și expunerea de date. Atacatorul controlează parțial datele pe care PHP le întâlnește în memoria invalidă prin requesturi HTTP special construite. Requesturile mari sunt o cale de a pune presiune pe memorie, dar problema nu se reduce la consum de resurse.

Un detaliu care contează operațional: vulnerabilitățile afectează toate serverele web care rulează PHP 5.4 sau o versiune mai nouă. Sursa menționează că PHP stă la baza a aproape 70% dintre site-uri și că platforme precum WordPress și Magento depind de el. Asta explică de ce o problemă de runtime are un blast radius mult mai mare decât un plugin compromis.

De ce un WAF clasic pe request nu ajunge

Aici apare partea tehnică interesantă și, în opinia mea, cea mai utilă lecție pentru cine administrează infrastructură. Cloudflare scrie explicit că protecția împotriva php2shell a cerut mai mult decât reguli standard bazate pe request. Datele din request nu oferă mereu suficiente dovezi pentru a separa un exploit de trafic legitim. Răspunsul originii adaugă context: arată dacă exploitul a reușit sau nu, reducând fals pozitivele.

De aici a apărut „full transaction detection”, o capacitate nouă a WAF-ului care combină semnale din request și din response în aceeași tranzacție HTTP. Regulile de response pot bloca un răspuns al originii înainte să ajungă la cel care l-a cerut. Protecțiile php2shell sunt primele detecții managed lansate pe această capacitate. Am analizat mecanismul mai detaliat în materialul despre Cloudflare WAF care corelează request cu response, util dacă vrei să înțelegi ce se schimbă în modelul de protecție.

Cronologia livrării, din sursă: regulile au fost dezvoltate și implementate începând cu începutul lunii octombrie 2026, cu aproximativ nouă ore înainte de divulgarea publică. Din 21 octombrie, ora 03:02 UTC, clienții Cloudflare cu WAF, gratuit sau plătit, au fost protejați implicit. Cloudflare notează și că a livrat mitigări în timp ce vulnerabilitatea fusese scursă înainte de data oficială și că a observat trafic de atac îndreptat spre clienții săi. Echipa a urmărit volumul de potriviri și l-a corelat cu logica regulilor pentru a prinde mutațiile de payload prin care atacatorii încercau să ocolească protecțiile.

Pentru planurile Free, regulile au intrat în Cloudflare Managed Free Ruleset, cu ID-ul de ruleset menționat în sursă, fără nicio acțiune din partea clientului. Pentru planurile plătite (Professional, Business, Enterprise), protecția e în Cloudflare Managed Ruleset, iar sursa recomandă verificarea modului de deploy, ca să fie în block, nu doar în log. În plus, o regulă de blocare implicită pentru semnături cu încredere ridicată a fost publicată în noul Cloudflare Managed Response Firewall Default, pentru toate planurile, inclusiv Free.

Ce trebuie să facă un administrator, în ordine

Recomandările mele, separate de constatările sursei:

  1. Confirmă versiunea de PHP pe fiecare mediu: producție, staging, medii uitate. Majoritatea incidentelor de acest tip apar pe un mediu secundar pe care nimeni nu îl mai patchuiește.
  2. Verifică cine controlează PHP-ul. Dacă e hosting partajat sau managed, deschide ticket la provider și cere explicit versiunea și confirmarea aplicării update-ului de securitate. Nu presupune că s-a întâmplat.
  3. Dacă ai Cloudflare, intră în Security > Security Analytics > Events, filtrează după ID-urile regulilor din anunț și inspectează requestul, acțiunea și path-ul. Așa vezi dacă protecția chiar s-a declanșat pe aplicația ta, nu doar dacă e activă la nivel de cont.
  4. Dacă folosești planuri plătite, confirmă că Managed Ruleset e pe block, nu pe log. O regulă în log nu oprește nimic.
  5. Patchuiește PHP. Sursa e clară: WAF-ul e un strat suplimentar de defense-in-depth, nu un substitut. Administrarea codului site-ului sau a plugin-urilor nu rezolvă problema, pentru că defectele sunt în runtime.
  6. Redu suprafața de atac: restricționează upload-urile inutile și limitează dimensiunea fișierelor încărcate. Sursa menționează aceste măsuri ca reducere de expunere, dar subliniază că nu înlocuiesc fix-ul de PHP.

Un punct de disciplină internă: nu transforma un audit automat sau o notificare de scanare în concluzia „suntem infectați” sau „am pierdut bani”. O potrivire de regulă înseamnă că un request a fost blocat. Nu dovedește succesul unui exploit și nici absența altuia. Verificarea se face pe probe: loguri de acces, evenimente WAF, versiuni de PHP confirmate de provider.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin online pe WordPress sau Magento, un site de content și câteva zeci de mii de lei pe lună în trafic plătit, php2shell nu e o știre pentru echipa tehnică din altă clădire. E o problemă de business. Un site care cade în mijlocul unei campanii sau care expune date de clienți îți afectează direct veniturile și încrederea.

Scenariu ipotetic, ca să fie clar: un magazin cu trafic constant, pe un hosting partajat unde PHP-ul e gestionat de provider. Cloudflare blochează atacurile cunoscute. Dacă PHP-ul rămâne neactualizat, iar un atacator găsește o variantă care nu se potrivește pe semnăturile existente, protecția devine mai subțire. Nu pot spune cât de probabil e, sursa nu oferă date de exploatare pe scară. Pot spune însă că ordinea corectă a pașilor e fix cea de mai sus, iar patch-ul nu se amână pentru că „avem WAF”.

Al doilea aspect, de marketing: paginile de produs, formularele de lead și checkout-ul depind de un runtime care tocmai a primit două CVE-uri. Dacă ai un plan de continuitate, e momentul să îl citești. Dacă nu ai, e momentul să schițezi unul: cine sună providerul, cine verifică evenimentele WAF, cine comunică cu clienții dacă apar probleme. Aici AI-ul te ajută la analiză și planificare, de exemplu la structurarea unui checklist sau la trierea evenimentelor, dar decizia și execuția rămân umane. Un media buyer senior știe ce se oprește primul când site-ul nu răspunde și ce spune clientului.

Dacă lucrezi cu agenții sau furnizori, cere confirmări scrise. „Cred că e ok” nu e un răspuns. Vrei versiunea de PHP, data aplicării update-ului și capturi din evenimentele WAF, dacă e cazul.

Limitele informației și ce nu știm încă

Sursa nu oferă cifre despre câți clienți au fost vizați, nu detaliază volume de atac și nu promite un calendar pentru patch-uri la nivel de hosting. Nu știm nici cât de repede au apărut variante noi de payload după divulgare, deși Cloudflare spune că își actualizează regulile pe măsură ce apar tehnici noi, iar changelog-ul e locul unde se vede.

Un lucru e sigur din material: regulile sunt deja active pentru toate planurile cu WAF, implicit. Dacă ai cont Cloudflare și nu ai modificat setările, protecția e pornită. Asta nu înseamnă că serverul e reparat.

FAQ

Trebuie să fac ceva dacă folosesc Cloudflare pe planul Free? Nu, pentru activarea protecției. Regulile au fost publicate în Managed Free Ruleset și se aplică automat. Ce trebuie să faci este să actualizezi PHP, pentru că WAF-ul e doar un strat suplimentar.

Actualizarea plugin-urilor sau a temei rezolvă problema? Nu. Vulnerabilitățile sunt în runtime-ul PHP, nu în codul aplicației. Trebuie actualizat PHP pe server sau cerut providerului de hosting să aplice update-ul de securitate.

Unde văd dacă protecția a blocat ceva pe site-ul meu? În Security > Security Analytics > Events, filtrând după ID-urile regulilor din anunțul Cloudflare. Inspectează requestul, acțiunea și path-ul. O potrivire înseamnă un request blocat, nu dovada unui atac reușit.

Concluzia ALLSoft Agency

AI-ul ajută la analiză, la structurarea unui checklist de remediere și la trierea evenimentelor, dar nu decide și nu patchuiește nimic. Deciziile și execuția rămân umane, iar la mijloc e un media buyer sau un om de infrastructură care știe ce prioritizează. Pasul concret îl face ALLSoft Agency: verificăm împreună ce ai activat în Cloudflare, ce versiune de PHP rulează și ce urmează în ordinea corectă, fără hype și fără promisiuni pe care nu le putem susține cu date.