In breve: secondo le proprie dichiarazioni, Cloudflare ha attive regole di protezione contro PHP2Shell dal 21 ottobre 2026, alle 03:02 UTC, anche per i clienti del piano gratuito. Le regole riducono il rischio per il traffico che passa da Cloudflare. Non agiscono se il server di origine è raggiungibile direttamente e non sostituiscono l'aggiornamento di PHP. Chi usa Cloudflare dovrebbe verificare modalità delle regole, protezione dell'origine e stato della patch.
Il punto di partenza: protezione già prima della patch
Con PHP2Shell Cloudflare è stata insolitamente rapida. Secondo il blog di Cloudflare, le regole di protezione erano attive già diverse ore prima della pubblicazione ufficiale degli aggiornamenti PHP alle 14:00 UTC. Cloudflare ha inoltre riferito di aver osservato tentativi di attacco ai clienti e che gli aggressori modificavano i propri schemi per aggirare le regole.
Molti gestori ne hanno concluso: «Siamo dietro Cloudflare, quindi siamo protetti.» Questo è vero solo in parte. Questo articolo spiega che cosa le regole coprono davvero. Una valutazione generale tra firewall e aggiornamento è nell'articolo WAF o aggiornamento?.
Cosa ha distribuito Cloudflare contro PHP2Shell
Secondo le indicazioni nel blog di Cloudflare, i componenti sono tre:
| Piano | Protezione secondo Cloudflare | Cosa dovrebbe fare |
|---|---|---|
| Free | nuove regole nel Managed Free Ruleset, attive automaticamente | verificare che il dominio passi da Cloudflare |
| Pro, Business, Enterprise | regole adeguate nel Managed Ruleset | assicurarsi che il ruleset sia su «Block» |
| tutti i piani | regola standard nel nuovo firewall delle risposte | non disattivare nulla, osservare gli eventi |
Il terzo componente è nuovo. Cloudflare lo chiama «full transaction detection»: il WAF considera non solo la richiesta, ma anche la risposta del server. Il motivo secondo Cloudflare: la sola richiesta non sempre basta per distinguere con certezza un attacco dal normale traffico. PHP2Shell è il primo impiego di questa funzione nelle regole gestite.
I limiti delle regole di Cloudflare
Per quanto utili, le regole hanno limiti chiari, che in parte Cloudflare stessa indica:
- Solo traffico tramite Cloudflare: le regole controllano ciò che passa da Cloudflare. Se il server di origine è raggiungibile direttamente al suo indirizzo IP, un aggressore può aggirare la protezione.
- Nessun annullamento: secondo Cloudflare, una regola sul lato risposta può trattenere la risposta, ma non annullare ciò che è già avvenuto sul server.
- Schemi di attacco mutevoli: Cloudflare adegua continuamente le regole, perché gli aggressori modificano le richieste. Tra la nuova variante e la nuova regola può esserci un vuoto.
- Nessuna sostituzione dell'aggiornamento: Cloudflare raccomanda espressamente di aggiornare PHP nonostante il WAF. Neppure un aggiornamento del codice applicativo o dei plugin elimina le vulnerabilità.
- Caso particolare CVE-2026-115560: secondo l'integrazione di Cloudflare del 23 ottobre, la regola non interviene se il nome per il session upload progress è stato modificato nella configurazione. Maggiori informazioni su questa segnalazione in CVE-2026-115560.
Che cosa dicono le richieste bloccate e che cosa no
Dopo la segnalazione, molti clienti guardano i propri eventi di sicurezza e vi trovano richieste bloccate. Ciò mostra anzitutto solo che il Suo dominio è stato sondato e che la regola è intervenuta. Un'intrusione non è con ciò dimostrata. Viceversa, un elenco eventi vuoto non è un cessato allarme: se un attacco è stato diretto al server di origine o è avvenuto prima del 21 ottobre, presso Cloudflare non compare affatto.
Più affidabile è il confronto con i log del server web stesso. Richieste che arrivano lì ma non provengono da indirizzi Cloudflare indicano un accesso diretto. Conservi questi log dal 20 ottobre, come consiglia la stampa specializzata. Cloudflare avverte inoltre che le limitazioni agli upload possono ridurre il rischio, ma non sostituiscono l'aggiornamento di PHP.
La vulnerabilità più frequente dietro Cloudflare non è la regola, ma la strada che la aggira: un server di origine che risponde direttamente al suo indirizzo IP o tramite un sottodominio non protetto.
Elenco di verifica per i clienti Cloudflare
Questi passaggi possono essere svolti da Lei o dal Suo fornitore di servizi in tempi brevi:
- Verificare piano e modalità delle regole: con i piani a pagamento, controllare nella dashboard che il Managed Ruleset sia attivo in modalità «Block».
- Guardare gli eventi di sicurezza: nei Security Events verificare se compaiono richieste bloccate. Ciò mostra se i Suoi domini sono già stati un bersaglio.
- Esaminare i record DNS: ogni record che punta al server web ma non passa da Cloudflare è una possibile scorciatoia. Tipici sono i sottodomini per staging, FTP o posta sullo stesso server.
- Isolare l'origine: configurare il server web in modo che accetti HTTP e HTTPS solo da Cloudflare, ad esempio con un firewall che usi gli intervalli di indirizzi pubblicati da Cloudflare o tramite un tunnel. Come si fa in generale lo descrive l'articolo Firewall per server web.
- Testare l'accesso diretto: verificare dall'esterno se l'origine risponde senza Cloudflare.
- Aggiornare PHP e riavviare: le regole sono la seconda linea. La prima è PHP a uno stato corretto con il riavvio di tutti i processi PHP.
Per il passo 5 basta un test innocuo che richiede solo le intestazioni. L'indirizzo IP è un segnaposto per il Suo server di origine:
# Il server di origine risponde direttamente, aggirando Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Se qui arriva una normale risposta del Suo sito, l'origine è raggiungibile direttamente e la protezione di Cloudflare è aggirabile.
Come aiuta concretamente PHP SOS?
- Verifica della configurazione: controlliamo modalità delle regole, record DNS e accesso diretto al server di origine.
- Messa in sicurezza dell'origine: limitiamo il server web al traffico tramite Cloudflare, senza interrompere il Suo sito.
- Patch e prova: aggiorniamo PHP, riavviamo tutti i processi e documentiamo lo stato.
- Analisi degli eventi: esaminiamo le richieste bloccate e le confrontiamo con i log del server.
Come combiniamo regole WAF e misure transitorie lo descrive WAF e virtual patching.
Conclusione
Le regole di Cloudflare contro PHP2Shell sono un vero vantaggio, soprattutto perché sono arrivate presto e anche nel piano gratuito. Sono però uno scudo davanti alla porta, non una serratura alla porta. Chi sta dietro Cloudflare dovrebbe assicurare tre cose: regole in modalità Block, nessuna strada che aggiri il proxy e PHP a uno stato corretto.
Domande frequenti
Con il piano gratuito di Cloudflare sono protetto da PHP2Shell?
Secondo Cloudflare, anche i clienti Free ricevono automaticamente le regole di protezione. Agiscono però solo sul traffico che passa da Cloudflare e non sostituiscono l'aggiornamento di PHP sul server. Se il server di origine è raggiungibile direttamente, la protezione non interviene.
Che cosa devo impostare con i piani Cloudflare a pagamento?
Cloudflare consiglia ai clienti dei piani Pro, Business ed Enterprise di verificare che il Managed Ruleset sia in modalità Block. Se è solo su Registra, gli attacchi vengono rilevati ma non fermati.
Che cos'è la full transaction detection?
Una nuova funzione del WAF di Cloudflare che considera non solo la richiesta, ma anche la risposta del server. Così si può riconoscere se un tentativo di attacco ha effetto e la risposta può essere trattenuta. Ciò che sul server è già stato eseguito, secondo Cloudflare, non viene annullato.
Cloudflare copre anche CVE-2026-115560?
Cloudflare ha integrato il 23 ottobre il proprio articolo con CVE-2026-115560. Secondo Cloudflare la regola corrispondente non interviene se il nome per il session upload progress è stato modificato nella configurazione PHP. Indipendentemente da questo, php.net raccomanda di impostare session.upload_progress.enabled=0.