Cloudflare a deschis un Capture the Flag pe HackerOne în care cercetătorii încearcă să spargă un sandbox PHP vulnerabil aflat în spatele WAF-ului propriu. Scopul declarat este testarea regulilor care blochează exploaturile php2shell, nu verificarea unor clienți. Rezultatele ajută la întărirea detecțiilor pentru toate planurile, inclusiv Free.

Ce a anunțat Cloudflare, pe scurt

Sursa este un articol de blog Cloudflare (link de atribuire: Cloudflare Blog), publicat pe 27.10.2026 și actualizat pe 30.10.2026. Faptele confirmate în material sunt următoarele. Cloudflare a montat o instalare PHP deliberat vulnerabilă într-un Cloudflare Container, cu PHP 8.5.11 standard, Apache 2 prin mod_php și un index.php gol. În fața ei rulează regulile WAF implicite pentru cele două vulnerabilități din spatele valului numit php2shell, CVE-2026-109618 și CVE-2026-109619. În sandbox există un fișier /flag, iar mediul se resetează la câteva minute, inclusiv fișierul.

Provocarea cere un singur lucru: ocolirea WAF-ului, execuție de cod sau comandă PHP controlată de atacator printr-un POST autorizat, recuperarea conținutului din /flag și verificarea lui în interfața CTF înainte de reset. Raportarea se face privat pe HackerOne, cu titlul „PHP CTF”, cu endpoint, payload complet, secvență de request-uri, capturi brute request/response, explicația ocolirii, ID-ul încercării și timestamp-urile UTC.

Sunt excluse explicit: divulgarea de fișiere fără execuție de cod, execuția fără recuperarea și verificarea flag-ului, exploaturile doar locale, redescoperirea vulnerabilităților PHP deja cunoscute și lanțurile parțiale. Recompensa se acordă doar pentru o metodă de ocolire a firewall-ului care este material distinctă. Dacă doi cercetători folosesc același mecanism de bypass, restul diferențelor nu contează: al doilea raport este duplicat. Cloudflare ia decizia finală.

Testarea este autorizată doar pe endpoint-urile /php/* ale hostname-ului provocării, doar cu POST. În afara scopului: alte servicii Cloudflare, accesul direct la infrastructura de sub WAF, proiectul PHP upstream, sisteme terțe. Fără denial of service, fără scanare de volum, fără persistență, fără atacuri pe alți participanți. La 429 sau 503, se face back off.

Concluzia editorială a Cloudflare, importantă de reținut: WAF-ul nu înlocuiește patch-ul. Blocarea răspunsului oprește datele să ajungă la atacator, dar nu anulează ce s-a executat deja la origine. Cine rulează PHP trebuie să urmeze cele mai recente avize de securitate și să aplice update-urile.

Atât ca rezumat de fapte, suficient.

De ce un CTF public este o decizie de inginerie, nu de marketing

Un firewall aplicativ este un produs despre care e greu să spui adevărul. Clienții vor să audă că blochează tot, iar realitatea e că fiecare regulă are margini. Cloudflare alege să-și expună marginile în public, cu un sandbox controlat, în loc să le descopere cineva într-un incident real. Asta e o poziționare matură, dar are și un cost: orice bypass găsit devine cunoscut, iar presiunea pe echipa de detecții crește.

Merită subliniat un detaliu care spune multe despre context. În aceeași săptămână, materialul menționează compromiterea a opt certificate intermediare eMudhra și valul php2shell, iar Cloudflare spune că a livrat actualizări de client și mai multe mitigări, a adăugat reguli WAF și o funcție nouă numită full transaction detection, disponibilă pe toate planurile, inclusiv Free. Un CTF care rulează imediat după un astfel de eveniment nu este un exercițiu de imagine. Este colectare de date reale despre cum arată încercările de exploatare în trafic.

Aici e și partea incomodă, pe care agențiile o văd rar: dacă regulile WAF se schimbă în timpul provocării, un test făcut de client acum două săptămâni nu mai spune nimic despre starea de azi. Cloudflare spune explicit că a întărit protecțiile php2shell existente și a creat detecții noi, iar modificările de reguli sunt în changelog-ul WAF. O verificare incompletă a unui site nu dovedește absența protecției. Dovedește doar că nu ai găsit încă ce cauți.

Ce înseamnă un WAF bine testat și ce nu

Există o confuzie frecventă pe care merită să o demontăm. Un WAF nu este un antivirus pentru site și nu este un patch. Este un filtru care stă în fața originii și încearcă să recunoască pattern-uri de atac. Când un CVE nou iese în public, WAF-ul cumpără timp: blochează exploaturile cunoscute până când aplicația primește update. Dacă exploaturile reușesc să treacă, timpul cumpărat e mai scurt.

CTF-ul Cloudflare testează exact această fereastră de timp. Un cercetător care reușește să execute cod în sandbox a demonstrat că o regulă are o gaură. Nu a demonstrat că Cloudflare e nesigur, nici că un client anume e vulnerabil. A demonstrat că o detecție specifică poate fi ocolită cu un payload specific, într-un mediu specific. Diferența e uriașă și e exact genul de diferență pe care un raport automat de audit o pierde.

Recomandarea practică, pentru oricine administrează un site: tratează un WAF ca pe o centură de siguranță, nu ca pe frâna de mână. Centura ajută, dar nu ține locul reviziei tehnice. Dacă rulezi PHP, verifică versiunea, aplică update-urile din avize și abia apoi discută despre reguli WAF. Ordinea asta nu e negociabilă.

Ce poți verifica singur, fără să faci pentesting

Nu ai nevoie de un CTF ca să afli dacă ai o problemă de bază. Ai nevoie de disciplină. Iată un set de pași pe care îi poți propune echipei tehnice, fără să atingi sisteme care nu îți aparțin.

Primul pas: inventarul. Ce versiune de PHP rulează în producție, ce extensii sunt active, ce framework și ce versiune. Aici intervine și o discuție de business, pentru că versiunile vechi sunt și o problemă de performanță, nu doar de securitate. Dacă ai un site lent și un CMS vechi, cele două probleme se rezolvă împreună.

Al doilea pas: procesul de patch. Cine citește avizele, în cât timp aplică update-urile, ce se întâmplă dacă un update strică un plugin. Multe magazine online din România au un singur om care știe ce e în spatele site-ului. Ăsta e riscul real, nu lipsa unui WAF.

Al treilea pas: supravegherea. Loguri de WAF, alerte pe pattern-uri de atac, un loc unde se vede dacă cineva încearcă. Dacă nu ai loguri, nu ai cum să știi dacă ești atacat, iar absența alertelor nu dovedește absența atacurilor.

Al patrulea pas: testarea controlată. Aici e locul unde un CTF public își arată valoarea, dar și limita. Poți verifica dacă site-ul tău blochează un payload cunoscut, în mediul tău, cu acordul tău. Ce nu poți face este să extragi concluzii despre securitatea generală dintr-un singur test. O verificare incompletă nu dovedește nimic, în nicio direcție.

Al cincilea pas, pe care aproape nimeni nu îl face: separarea mediilor. Dacă site-ul de producție și mediul de test stau pe același server cu aceleași credențiale, WAF-ul nu te salvează de tine însuți.

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

Dacă ai un magazin online, un site de servicii sau un blog care aduce lead-uri, știrea asta nu îți cere să înveți să spargi PHP. Îți cere să accepți un lucru simplu: securitatea site-ului este o variabilă de business, nu un capitol tehnic pe care îl delegi și îl uiți.

Gândește-te la ce se întâmplă când un site cade sau când un atacator modifică ceva în baza de date. Reclamele rulează în continuare. Bugetul se consumă. Traficul ajunge pe o pagină care nu mai convertește. Nimeni nu vede asta în dashboard-ul de ads, pentru că platforma raportează clicuri, nu indisponibilitate. Paguba nu se vede în CPA, se vede în vânzările care lipsesc și pe care nimeni nu le mai poate măsura.

Recomandarea mea concretă, pentru un antreprenor român: pune pe lista de verificare trimestrială trei întrebări. Cine răspunde dacă site-ul e compromis în weekend. Când s-a făcut ultimul update de PHP sau de CMS. Dacă există un backup restaurat cu succes în ultimele șase luni, nu doar creat. Dacă răspunsul la oricare dintre ele e „nu știu”, problema nu e tehnică, e de proces.

Pentru marketeri, mai e un aspect. Instrumentele de măsurare și tag-urile de pe site sunt și ele suprafață de atac. Un script terț compromis poate injecta conținut sau poate fura date de formular. Când discuți cu developerul despre un tag nou, întreabă și cine îl aprobă și ce se întâmplă dacă furnizorul îl schimbă peste noapte. Nu e paranoia, e igienă.

Un ultim punct de onestitate: un incident de securitate nu se judecă după un audit automat. Un scanner care raportează „mediu” sau „ridicat” nu îți spune dacă ai pierdut bani, dacă ai încălcat o obligație legală sau dacă datele clienților au plecat. Acele concluzii cer investigație, loguri și un om care le citește. Până atunci, ai ipoteze, nu constatări.

Cum arată un plan rezonabil de reacție

Dacă vrei să transformi discuția într-un plan, începe cu ce este măsurabil azi. Versiuni de software instalate. Data ultimului update. Existența backup-ului și data ultimei restaurări de test. Cine are acces la panoul de administrare și cu ce drepturi. Acestea sunt fapte, nu păreri.

Apoi definește ce este ipoteză. „Suntem protejați de WAF” este o ipoteză până când cineva a testat un payload cunoscut în mediul tău. „Nu avem date sensibile” este o ipoteză până când cineva s-a uitat la ce colectează formularul de contact. „Furnizorul nostru de hosting se ocupă” este o ipoteză până când ai citit contractul.

În final, stabilește ce faci când ceva se mișcă. Cine anunță, cine izolează, cine comunică. Un plan de o pagină, scris înainte de incident, valorează mai mult decât orice dashboard.

FAQ

Trebuie să particip la CTF ca să îmi protejez site-ul? Nu. Provocarea este pentru cercetători de securitate, se desfășoară pe infrastructura Cloudflare și are reguli stricte de scope. Pentru site-ul tău, pașii utili sunt update-urile, backup-urile testate și logurile, nu exercițiul public.

Dacă am WAF de la Cloudflare, sunt acoperit? WAF-ul reduce expunerea la exploaturi cunoscute, dar Cloudflare spune explicit în material că nu înlocuiește patch-ul. Blocarea la răspuns nu anulează ce s-a executat deja la origine. Deci: da, ajută, nu, nu e suficient.

Un raport de scanare care zice „vulnerabil” înseamnă că am pierdut bani? Nu automat. Un rezultat automat este un semnal, nu o dovadă de impact. Verifică manual, cu loguri și cu context, înainte să tragi concluzii despre vânzări, CPA sau obligații legale.

AI-ul ajută, dar decizia rămâne la om

Un model de limbaj poate să îți structureze inventarul de versiuni, să îți pună în ordine pașii de remediere, să îți traducă un aviz de securitate într-un limbaj care se citește într-o ședință. Poate chiar să îți facă un draft de plan de reacție. Ce nu poate face este să decidă în locul tău ce riști și ce nu, și nu poate executa schimbarea la origine.

Execuția cere un om care știe ce atinge: developerul care face update-ul, media buyer-ul care verifică dacă reclamele mai rulează pe un site funcțional, omul care confirmă că backup-ul chiar se restaurează. La ALLSoft Agency pașii aceștia se fac în ordine, cu responsabil pe fiecare, fără promisiuni de cifre pe care nu le putem susține. Dacă vrei să vezi cum arată procesul pe partea de achiziție și măsurare, începe de la ALLSoft Agency.

Un ultim gând, legat de contextul mai larg. În aceeași zi am scris despre un incident în care agenți AI au fost folosiți pentru a sparge o platformă, într-o analiză despre ce înveți din incidentul Chainalysis. Lecția se repetă: uneltele accelerează atât atacul, cât și apărarea. Diferența o face cine știe să le folosească cu cap și cine are un proces când ceva merge prost.