Cloudflare e il WAF bypassato: come un percorso di servizio ha esposto server in tutto il mondo

Cloudflare è oggi uno dei pilastri dell’infrastruttura di Internet. Migliaia di aziende, incluse realtà enterprise, fintech, piattaforme cloud e servizi critici, affidano a Cloudflare la protezione perimetrale delle proprie applicazioni Web. Il suo ruolo non è marginale: Cloudflare si posiziona davanti agli origin server dei clienti, assorbendo traffico, terminando connessioni TLS, filtrando richieste malevole e decidendo, in modo centralizzato, chi può parlare con l’applicazione e chi no. Per molte realtà, Cloudflare rappresenta di fatto il perimetro di sicurezza.

Tra i vari servizi offerti da Cloudflare c’è anche il Web Application Firewall (WAF): non è soltanto un sistema di rilevamento di attacchi comuni, ma un vero e proprio controllore di accesso logico. Attraverso regole personalizzate, è possibile bloccare interamente Internet, consentire l’accesso solo da reti aziendali, filtrare header, metodi HTTP, percorsi specifici o impostare combinazioni complesse di condizioni.

Gli sviluppatori, avvalendosi di un meccanismo di protezione come il WAF, possono assumere l’origin server non sia direttamente esposto e che molte richieste potenzialmente pericolose siano fermate prima ancora di raggiungere l’applicazione che si affaccia sul Web.

L’anomalia: quando il WAF smette di proteggere

Durante una revisione delle misure di difesa attive su più applicazioni protette da Cloudflare, tutte configurate in modalità default deny, è emerso un comportamento incoerente.

I ricercatori di FearsOff, azienda specializzata con sede a Dubai, hanno accertato che qualsiasi richiesta diretta percorsi ordinari – su server protetti con il WAF Cloudflare – restituiva correttamente la block page. Tuttavia, avanzando una richiesta verso /.well-known/acme-challenge/{token}, la risposta non proveniva più da Cloudflare ma direttamente dall’applicazione di backend e quindi dall’origin server. Questo dettaglio è cruciale: in quel caso particolare, il WAF non stava più mediando la richiesta e quindi cessava di svolgere la sua azione di firewall Web.

Immagine tratta da “How we mitigated a vulnerability in Cloudflare’s ACME validation logic” (Cloudflare)

L’eccezione ACME: perché esiste

Il protocollo ACME serve per emettere certificati TLS. Utilizzando il metodo HTTP-01, un’Autorità di certificazione deve poter leggere un file preciso nel percorso /.well-known/acme-challenge/{token}.

Si tratta di un’eccezione che permette la validazione automatica dei certificati digitali senza dover disabilitare il WAF. Ne parliamo anche nell’articolo su come trasformare un Mini PC in un server sicuro e professionale.

La richiesta inviata al percorso ACME, quindi, non ha nulla di speciale dal punto di vista HTTP: è una normale GET. La sua particolarità sta nel contesto. È una richiesta attesa, limitata, estremamente specifica. L’idea è consentire solo quella lettura, senza aprire alcun altro canale verso l’applicazione.

Il comportamento reale osservato

Il bug emerge quando il percorso /.well-known/acme-challenge/{token} è trattato come una corsia privilegiata. E nel caso di Cloudflare, le regole del WAF non erano applicate a questo specifico percorso.

Il rischio nasce evidentemente nel momento in cui l’origin server diventa raggiungibile dall’esterno, anche se solo attraverso un singolo percorso. Una volta che esso risponde, entrano in gioco tutte le sue caratteristiche reali: framework, routing, middleware, error handling, configurazioni di debug. Tutto ciò che prima viveva “dietro” il WAF e risultava protetto ora ha un canale di esposizione.

In ambienti Java, ad esempio, il semplice fatto di poter raggiungere il servlet container consente di sfruttare espedienti tecnici che possono portare a endpoint di gestione del sistema normalmente non esposti.

Nelle applicazioni JavaScript server-side, come quelle basate su rendering dinamico, le risposte possono includere dati operativi che si assumeva non fossero mai visibili pubblicamente.

In molti stack PHP, in cui ogni richiesta è instradata attraverso un front controller, anche una 404 passa comunque dal codice applicativo, riattivando vulnerabilità latenti come LFI (Local File Inclusion) o disclosure di file di sistema.

Una LFI si verifica quando un’applicazione costruisce dinamicamente il percorso di un file da leggere o includere utilizzando un input controllabile dall’utente, senza validarlo in modo corretto. In pratica, l’attaccante riesce a “convincere” l’applicazione a leggere file che non fanno parte della pagina, ma che esistono sul server. File come /etc/passwd, /etc/hosts, configurazioni di servizi, chiavi, log o file di ambiente non contengono codice eseguibile, ma rivelano informazioni preziose sulla struttura del sistema e sull’ambiente in cui gira l’applicazione.

La disclosure di file di sistema è l’effetto pratico di questo tipo di vulnerabilità. Anche senza eseguire codice, poter leggere file locali significa ottenere nomi di utenti, percorsi interni, variabili d’ambiente, credenziali, segreti applicativi o riferimenti ad altri servizi interni. Queste informazioni sono spesso sufficienti per preparare attacchi successivi molto più gravi, come l’accesso a database, movimenti laterali o l’abuso di API interne.

Un aspetto ancora più critico: le regole ignorate

Il punto più delicato non riguarda solo il routing, ma il fatto che anche le regole WAF impostate a livello account Cloudflare non venivano valutate. Test con header esplicitamente bloccati dimostravano un comportamento coerente sui percorsi normali e completamente diverso sul percorso ACME.

Qualunque protezione basata su header, metodo o condizioni avanzate era di fatto disattivata per il path /.well-known/acme-challenge/.

In molte applicazioni legacy, soprattutto quelle sviluppate quando il perimetro di rete era considerato affidabile, alcuni header HTTP sono usati direttamente dal codice applicativo per prendere decisioni logiche. Header come X-Forwarded-Host, X-Original-URL o quelli usati per forzare un override del metodo HTTP non sono sempre validati perché si presume che possano essere impostati solo da componenti interni e fidati, come proxy o load balancer.

In una configurazione corretta, è il WAF a fare da filtro: blocca, riscrive o elimina questi header prima che la richiesta raggiunga l’applicazione. Il codice, quindi, può permettersi di “fidarsi” del loro contenuto. Con il bypass sul percorso /.well-known/acme-challenge/, però, questo presupposto cadeva. Le richieste arrivavano all’origin server senza passare dai controlli previsti e quegli header potevano essere forniti direttamente da chiunque su Internet. In pratica, l’applicazione iniziava a fidarsi di dati controllati dall’attaccante, perché la barriera che doveva separarli semplicemente non veniva applicata.

La correzione di Cloudflare e la lezione appresa

Il 27 ottobre 2025 Cloudflare ha distribuito una correzione che ha riallineato il comportamento del WAF, applicando le regole anche alle richieste dirette a /.well-known/acme-challenge/. I test successivi hanno confermato l’effettiva risoluzione del problema.

La collaborazione tra i ricercatori e team di sicurezza come quello di Crypto.com, insieme al coinvolgimento diretto del CEO Cloudflare Matthew Prince, ha permesso una risoluzione rapida e coordinata.

La lezione, però, resta valida per tutti. Ogni eccezione è codice critico, soprattutto quando ridefinisce chi può parlare direttamente con l’origin server. Nel campo della sicurezza, non esistono percorsi “di servizio” innocui: esistono solo percorsi che rispettano il perimetro e percorsi che lo spostano.

Quando il problema è stato scoperto e segnalato, nell’ottobre 2025, l’obiettivo prioritario non era raccontarlo pubblicamente, ma ridurre il rischio reale per tutti gli utenti. Rendere noto un bypass WAF globale prima della correzione avrebbe significato fornire a chiunque un manuale operativo per colpire migliaia di applicazioni che, in quel momento, non avevano modo di difendersi. Per questo motivo, il dettaglio tecnico è rimasto riservato mentre Cloudflare lavorava alla correzione.

Oggi, lasciato trascorrere un periodo di sicurezza sufficiente, i ricercatori di FearsOff hanno condiviso tutti i dettagli tecnici e Cloudflare stessa ha pubblicato un’analisi tecnica incentrata sulla medesima problematica.