In breve: la WAF al posto dell'aggiornamento non funziona con PHP2Shell. Un Web Application Firewall, cioè un filtro davanti al sito, controlla le richieste e può bloccare modelli di attacco noti. La falla stessa si trova però nell'interprete PHP e scompare solo con l'aggiornamento e il riavvio di tutti i processi PHP. Una WAF è uno strato aggiuntivo sensato e un ponte per pochi giorni, non la soluzione.
Perché la domanda si pone così spesso proprio ora
Nella settimana di PHP2Shell molti gestori hanno letto una notizia apparentemente buona: secondo i propri dati, Cloudflare ha regole di protezione attive dal 21/10/2026, ore 03:02 UTC, anche per i clienti del piano gratuito. Chi è già dietro Cloudflare o un'altra WAF si chiede comprensibilmente se l'aggiornamento sia ancora urgente.
La risposta onesta è sì. Cloudflare stesso pone dei limiti: regole basate soltanto sui dati della richiesta non bastano, per questo il servizio controlla anche la risposta del server. Cloudflare ha inoltre osservato modelli di attacco modificati. E la protezione funziona solo per il traffico che passa effettivamente da Cloudflare. I dettagli su questo fornitore li descrive Regole di protezione Cloudflare contro PHP2Shell. Qui si tratta della valutazione di principio, indipendente dal fornitore.
Che cosa vede una WAF e che cosa cambia un aggiornamento
Una WAF sta davanti all'applicazione. Vede ogni richiesta, la confronta con le regole e la lascia passare, la blocca o la registra. Non sa come PHP elabori internamente la richiesta. Le due falle di PHP2Shell nascono però proprio lì: CVE-2026-109618 in una condizione di esaurimento della memoria mentre i dati della richiesta sono inizializzati solo in parte, CVE-2026-109619 a causa di uno stato interno che persiste dopo una richiesta nello stesso worker.
L'aggiornamento corregge questo codice. Dopo di esso la causa è eliminata, a prescindere da come appaia una richiesta. Chi vuole capire in quale punto del ciclo di una richiesta ciò avvenga trova le basi in Il ciclo di vita della richiesta in PHP.
WAF al posto dell'aggiornamento: il confronto onesto
| Criterio | Web Application Firewall | Aggiornamento PHP con riavvio |
|---|---|---|
| Che cosa viene risolto? | Niente, i modelli noti vengono intercettati | La causa nell'interprete PHP |
| Protezione contro nuove varianti di attacco | Solo se le regole vengono adeguate in tempo | Sì, la falla non esiste più |
| Aggirabile? | Sì, ad esempio tramite raggiungibilità diretta del server di origine | No, purché tutti i processi PHP siano stati riavviati |
| Rapidità | Spesso attiva subito | Dipende da versione, accesso e finestra di manutenzione |
| Effetti collaterali | Falsi allarmi, moduli o upload disturbati | Rari, con salti di versione servono test di compatibilità |
| Utilità con la prossima falla | Alta, se mantenuta | Nessuna, ogni falla richiede il proprio aggiornamento |
| Aiuta con PHP 8.1 e precedenti? | Come ponte | Solo tramite backport o migrazione |
La tabella mostra perché le due misure vanno insieme. La WAF è rapida e ampia, ma mai completa. L'aggiornamento è completo, ma solo per una determinata falla e non sempre possibile subito.
Un punto viene spesso trascurato nella pratica: una WAF modifica il comportamento del sito. Regole severe possono bloccare ordini legittimi, moduli di contatto o upload di file senza che qualcuno se ne accorga subito. Chi attiva una WAF in modo rigoroso durante la crisi dovrebbe quindi provare personalmente una volta i principali flussi del sito e controllare nei registri dei primi giorni le richieste bloccate ma legittime.
Come combinare le due cose in modo sensato
- Subito: verificare se è presente una WAF e se le regole adatte sono attive. Con Cloudflare nei piani a pagamento, secondo il fornitore, impostare il Managed Ruleset su Block.
- Subito: assicurarsi che il server di origine sia raggiungibile solo tramite la WAF, ad esempio con un'abilitazione nel firewall solo per i suoi intervalli di indirizzi. Altrimenti la protezione va a vuoto.
- Entro la prossima finestra di manutenzione: aggiornare PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure installare il backport confermato della distribuzione.
- Subito dopo: riavviare tutti i worker e i processi PHP e controllare che non giri più alcun vecchio processo. Non bastano nuovi file; di più in Dopo l'aggiornamento: riavviare PHP-FPM e tutti i worker.
- Poi: mantenere le regole della WAF, analizzare i falsi allarmi e impostare eccezioni mirate invece di disattivare le regole in blocco.
Con una WAF propria basata su ModSecurity e sul OWASP Core Rule Set si può ottenere qualcosa di simile; le basi le descrive Usare ModSecurity e OWASP Core Rule Set. Una forma particolare è il filtraggio delle richieste di upload al di fuori dei veri percorsi di upload, proposto da autori specializzati. Non è ufficiale, può rompere i moduli e va messo in esercizio solo dopo un test.
Né la WAF né l'aggiornamento rimuovono il malware introdotto in precedenza. Dopo la patch verifichi se dal 17/10/2026 sono comparse anomalie.
Quando non serve una WAF e quando non serve un fornitore
Una WAF non è obbligatoria per ogni sito. Un piccolo sito aziendale presso un hoster che applica la patch PHP con tempestività e lo conferma è spesso sufficientemente protetto senza WAF propria, se CMS e plugin sono aggiornati. Anche chi può aggiornare da sé il proprio server in breve tempo non ha bisogno della WAF come ponte.
Diventa sensata per shop, portali e applicazioni con molti moduli, per sistemi legacy che non si possono aggiornare subito e dove più siti devono essere protetti centralmente. Un fornitore le serve a tal fine solo se configurazione, test e manutenzione continua non sono coperti internamente.
Come aiuta concretamente PHP SOS?
- Verifichiamo se la Sua WAF si trova davvero davanti a tutti gli accessi e se il server di origine è raggiungibile direttamente.
- Configuriamo le regole o le adeguiamo e testiamo moduli, upload e interfacce per rilevare effetti collaterali.
- Installiamo l'aggiornamento PHP, riavviamo tutti i processi e documentiamo lo stato.
- Dove l'aggiornamento richiede tempo, facciamo da ponte con WAF e virtual patching e con una data fissa per la vera patch.
Conclusione
La domanda «WAF o aggiornamento» è mal posta. L'aggiornamento chiude la falla, la WAF fa guadagnare tempo e intercetta molto altro. Chi si affida solo alla WAF si fida di regole che gli aggressori possono aggirare. Chi applica solo la patch si ritrova alla prossima falla di nuovo senza ponte.
Domande frequenti
Una WAF basta come protezione da PHP2Shell?
No. Una WAF controlla il traffico dati e può bloccare modelli di attacco noti. La falla stessa si trova nell'interprete PHP e resta finché PHP non è aggiornato e riavviato. Cloudflare sottolinea espressamente che le sue regole non sostituiscono l'aggiornamento.
Dietro Cloudflare sono protetto automaticamente?
Solo per il traffico che passa effettivamente da Cloudflare. Se il server di origine è raggiungibile direttamente da Internet, la protezione viene aggirata. Nei piani a pagamento, secondo Cloudflare, dovrebbe verificare che il Managed Ruleset sia impostato su Block.
Una WAF vale la pena anche dopo l'aggiornamento?
Spesso sì. Una WAF può intercettare scansioni di massa, attacchi noti ai plugin e abusi delle pagine di login e fa guadagnare tempo con la prossima falla. Richiede però manutenzione e test, altrimenti i falsi allarmi disturbano l'attività.
Che cos'è il virtual patching?
Significa schermare temporaneamente una vulnerabilità con regole poste davanti all'applicazione, invece di modificare il codice. È un ponte fino al vero aggiornamento, non un sostituto.