Cloudflare sfida il proprio WAF: la sicurezza non si misura con una spunta verde

Un firewall applicativo può mostrare un grafico rassicurante: richieste bloccate, regole attive, attacchi respinti. Tutto verde. Eppure quella dashboard, da sola, non risponde alla domanda che conta davvero: qualcuno è riuscito a far eseguire codice al server nonostante quelle regole? Sono due misure diverse. La prima descrive l’attività di un filtro. La seconda descrive l’esito di un attacco contro il sistema che dovremmo proteggere.

Il 27 ottobre 2026 Cloudflare ha annunciato una challenge PHP Capture the Flag collegata al proprio programma Bug Bounty su HackerOne. Ha messo una versione vulnerabile di PHP dietro il suo WAF e ha invitato ricercatori esterni a cercare un percorso di compromissione. Non è la solita gara a trovare una stringa che passi attraverso una regola. Per essere eleggibile, il risultato deve arrivare fino all’esecuzione di codice, al recupero di un flag e alla sua verifica.

È una notizia interessante non perché improvvisamente Cloudflare abbia scoperto che un WAF può essere aggirato. È interessante perché sposta il metro di valutazione dal controllo dichiarato all’effetto dimostrato. Una differenza che riguarda chi sviluppa software, gestisce hosting, configura WordPress o approva un investimento in sicurezza. E che molte presentazioni commerciali preferiscono lasciare fuori dalla slide.

Un laboratorio costruito per mettere in discussione il filtro

Il bersaglio dichiarato è volutamente semplice: PHP 8.5.11 con estensioni standard, Apache 2 con mod_php, un file index.php vuoto e un file /flag nel container. Davanti c’è il WAF Cloudflare con le protezioni predefinite per le vulnerabilità PHP2Shell. Il sandbox viene ricreato periodicamente: secondo la pagina ufficiale della challenge, ogni cinque minuti.

Le due vulnerabilità sono CVE-2026-109618 e CVE-2026-109619, corrette dal progetto PHP il 21 ottobre con le release 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Sono difetti del runtime, non di un plugin o di una particolare applicazione. Il bollettino ufficiale PHP spiega che possono consentire esecuzione remota di codice senza autenticazione e raccomanda l’aggiornamento immediato.

Questa configurazione è un laboratorio, non una fotografia di ogni sito in produzione. Un WordPress con PHP-FPM, reverse proxy, plugin, cache e configurazioni personalizzate ha una superficie differente. Proprio per questo un eventuale risultato nella challenge non va trasformato automaticamente nella frase “ogni WAF è inutile”, così come l’assenza di un risultato pubblico non dimostra che tutti gli ambienti reali siano protetti.

Far passare una richiesta non significa compromettere un sistema

La distinzione più importante è nel criterio di successo. Un ricercatore può costruire una richiesta che non venga fermata dalla regola attesa. È un segnale utile: potrebbe indicare un falso negativo. Ma non basta per dimostrare un exploit. Una richiesta accettata può non attivare alcun comportamento pericoloso nel processo PHP; una risposta HTTP apparentemente innocua può invece nascondere un effetto già prodotto sul server.

Cloudflare richiede una catena verificabile: richiesta POST autorizzata verso gli endpoint della challenge, esecuzione di codice o comandi controllati nel sandbox, lettura del file /flag, verifica tramite interfaccia e report privato riproducibile su HackerOne. Servono sequenza delle richieste, evidenze tecniche, timestamp e un metodo materialmente distinto da eventuali segnalazioni precedenti. Non è sufficiente leggere un file senza RCE, ottenere soltanto un bypass del WAF o mostrare una prova locale non ripetibile.

La differenza tra “ho aggirato una regola” e “ho raggiunto l’obiettivo dell’attacco” è esattamente la differenza tra una metrica di componente e una metrica di sistema. Se stiamo valutando la sicurezza del servizio, non possiamo fermarci alla prima soltanto perché è più facile da contare.

Un controllo di sicurezza non diventa efficace perché è acceso. Diventa credibile quando sappiamo quali attacchi ferma, quali non ferma e come lo abbiamo verificato.

Il WAF vede il traffico. Non possiede una macchina del tempo

Un WAF lavora su ciò che riesce a osservare e a interpretare nel traffico. Può bloccare richieste sospette prima che arrivino all’origine, applicare regole gestite, correlare segnali e ridurre drasticamente l’esposizione. Ma non modifica retroattivamente lo stato interno di un processo vulnerabile. Cloudflare stessa, nella comunicazione della challenge, chiarisce che bloccare una risposta può impedire la fuoriuscita di dati, non annullare operazioni già eseguite sull’origin.

È una distinzione architetturale, non una critica a un fornitore specifico. La protezione edge e la correzione del runtime agiscono su livelli diversi. Se un input malevolo supera il filtro e attiva un difetto prima che l’applicazione inizi a elaborare la richiesta, nessuna validazione scritta nel controller Laravel o nel tema WordPress può correggere quel difetto. E una regola WAF, per quanto ben costruita, rimane una mitigazione soggetta a copertura, configurazione e nuovi percorsi di attacco.

Anche Google Cloud, nelle indicazioni del 21 ottobre aggiornate il 23, presenta le regole Cloud Armor come controlli compensativi: utili durante la risposta all’incidente, non sostitutivi dell’aggiornamento di PHP e del redeploy dei servizi. Il concetto è lo stesso, indipendentemente dal logo stampato sul prodotto.

Il valore del bug bounty è la prova, non il trofeo

Un programma di ricerca aperto ha un vantaggio concreto: mette alla prova le ipotesi del team che ha progettato le difese usando approcci che quel team potrebbe non aver previsto. Non garantisce di trovare ogni bypass e non equivale a una certificazione universale. Però costringe a formulare una domanda falsificabile: esiste una sequenza riproducibile che attraversa questa protezione e raggiunge questo obiettivo?

La challenge Cloudflare ha confini espliciti: soltanto il dominio dedicato e gli endpoint /php/* via POST, niente denial of service, scansioni massive, persistenza o attacchi a infrastrutture terze. Il report deve essere privato, nel perimetro del programma HackerOne, e un risultato verificato nell’interfaccia non sostituisce la segnalazione formale. La competizione è limitata nel tempo e può terminare senza preavviso. Questi vincoli non sono burocrazia accessoria: separano la ricerca autorizzata dall’idea piuttosto confusa che basti dichiararsi “ethical hacker” per testare qualunque cosa.

Al momento dell’annuncio non c’è, nelle fonti qui esaminate, una base per affermare che siano già stati premiati bypass specifici. E non serve inventare vincitori per capire il valore dell’esperimento: la metodologia è già la notizia.

Cosa dovrebbe imparare chi gestisce un sito PHP

Non sto suggerendo a chi amministra un e-commerce di riprodurre una RCE su un server di produzione. Sarebbe un modo creativo di trasformare un controllo di sicurezza in un incidente. La lezione operativa è più semplice, e forse proprio per questo meno scenografica.

1. Separare copertura e risultato

Una dashboard WAF dovrebbe essere letta insieme ai dati dell’origine: log applicativi e di sistema, eventi del runtime, richieste anomale, eventuali effetti persistenti e capacità di correlazione. “Bloccato” è una classificazione del filtro; “nessuna compromissione” è una conclusione che richiede evidenze ulteriori. In un contesto aziendale serio queste due affermazioni non dovrebbero mai finire nella stessa casella senza spiegazioni.

2. Tenere distinto il controllo compensativo dalla correzione

Se una vulnerabilità è nel runtime PHP, la risposta strutturale è aggiornare il runtime o applicare un backport verificato del fornitore, quindi assicurarsi che i processi che servono traffico stiano effettivamente usando la versione corretta. Avevo già affrontato il problema operativo nell’articolo PHP2Shell: la patch installata non è la patch attiva. Qui il passo ulteriore è non confondere il fatto che un WAF blocchi tentativi noti con la prova che la vulnerabilità sia stata eliminata.

3. Progettare test con un obiettivo verificabile

Un test utile specifica prima il confine autorizzato, l’azione che costituirebbe un fallimento, i segnali da raccogliere e i criteri per ripetere l’esperimento. Senza questi elementi si ottengono screenshot, punteggi e numeri da presentazione; non necessariamente conoscenza. È il medesimo principio che dovrebbe guidare i test di regressione, il monitoraggio delle code e la verifica di un deploy: misurare il comportamento che interessa, non soltanto il comando che abbiamo lanciato.

4. Conoscere i limiti della propria evidenza

Una prova su Apache mod_php non descrive automaticamente ogni variante PHP-FPM; una regola testata oggi non garantisce copertura domani; una segnalazione duplicata non vale come nuova tecnica. Un buon report di sicurezza espone anche ciò che non è stato verificato. È meno comodo da vendere, ma molto più utile a chi deve decidere.

La domanda che rimane dopo la challenge

Cloudflare ha fatto una scelta interessante: mettere pubblicamente sotto pressione le proprie difese, delimitare il campo e chiedere risultati riproducibili invece di accontentarsi del contatore degli attacchi respinti. Questo non rende il WAF infallibile e non riduce l’urgenza di correggere PHP. Rende più visibile una regola che dovrebbe essere banale in qualsiasi sistema software: una protezione va valutata rispetto all’obiettivo che promette di proteggere.

Se domani un fornitore mi mostra cento regole attive e diecimila richieste bloccate, la domanda non è se il grafico sia bello. È che cosa abbiamo verificato sull’origine, quali percorsi restano scoperti e come lo sappiamo. Perché un sistema può avere tutte le spunte verdi del mondo e continuare a eseguire il codice sbagliato. Solo che, finché guardiamo esclusivamente la dashboard, il problema ha la cortesia di non farsi vedere.