News

php2shell: Cloudflare blocca via WAF due falle critiche nel runtime PHP

Cloudflare ha attivato regole WAF contro CVE-2026-109618 e CVE-2026-109619 9 ore prima della disclosure. Il 23 ottobre una terza falla, CVE-2026-115560.

Redazione UptimeMag · 21 ottobre 2026 · 3 minuti di lettura

php2shell: Cloudflare blocca via WAF due falle critiche nel runtime PHP

Due vulnerabilità critiche nel runtime PHP, note come php2shell, sono state divulgate il 21 ottobre. Cloudflare ha reso noto di aver distribuito regole del proprio web application firewall per bloccare i tentativi di sfruttamento, e lo ha fatto prima ancora della pubblicazione ufficiale dell'advisory.

Cosa sono le due falle

Le vulnerabilità, tracciate come CVE-2026-109618 e CVE-2026-109619, riguardano la gestione della memoria quando PHP interrompe l'elaborazione di una richiesta HTTP in modo anomalo, per esempio per esaurimento di memoria. In quel momento PHP può finire per usare dati non completamente inizializzati o riferimenti a memoria già rilasciata. CVE-2026-109618 riguarda RCE via corruzione out-of-memory: la gestione dell'esaurimento memoria può lasciare i dati interni della richiesta parzialmente inizializzati, e la pulizia della richiesta può poi usare quei dati non validi. CVE-2026-109619 riguarda RCE via stato globale obsoleto: un worker PHP può mantenere riferimenti a memoria di richiesta liberata, e una richiesta successiva gestita dallo stesso worker può usare quello stato obsoleto.

Secondo l'advisory di AlmaLinux, PHP ha pubblicato le correzioni il 21 ottobre 2026 in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, con rilascio ufficiale fissato alle 14:00 UTC secondo i dati raccolti da SOCRadar. Il punteggio CVSS v4.0 assegnato dal team di sicurezza PHP è 9.2 per entrambe. Le versioni PHP non più supportate (8.1 e precedenti) restano fuori dal perimetro della patch ufficiale: secondo un'analisi di TuxCare, upstream patcha solo da 8.2 a 8.5, quindi PHP 8.1, 8.0, 7.x e 5.x non ricevono nulla da php.net.

La risposta di Cloudflare

Cloudflare racconta di aver sviluppato le regole fin dai primi di ottobre, distribuendole circa 9 ore prima della disclosure pubblica. Dalle 3:02 UTC del 21 ottobre tutti i clienti con WAF attivo, inclusi quelli sul piano Free, risultano protetti di default. L'azienda segnala di aver osservato traffico di attacco già prima della pubblicazione ufficiale, con tentativi di mutare il payload per aggirare le regole.

Per bloccare gli exploit in modo affidabile, Cloudflare ha introdotto una nuova funzione chiamata full transaction detection, che incrocia segnali della richiesta e della risposta all'interno della stessa transazione HTTP, potendo bloccare una risposta dell'origine prima che raggiunga il client. Le regole sono distribuite sotto due ruleset distinti: il Managed Free Ruleset (ID 77454fe2d30c4220b5701f6fdfb893ba) per i clienti gratuiti, con 7 regole dedicate, e il Managed Ruleset (ID efb7b8c949ac4650a09736fc376e9aee) per i piani Professional, Business ed Enterprise, anch'esso con 7 regole. Chi è su piano a pagamento deve verificare che il Managed Ruleset sia distribuito in modalità block.

L'aggiornamento del 23 ottobre

Due giorni dopo, il 23 ottobre, il progetto PHP ha pubblicato un avviso informativo su una terza falla, CVE-2026-115560, nella funzione di upload progress delle sessioni. Colpisce anche le versioni già corrette, inclusa la 8.5.12, e sarà risolta nella prossima release regolare. Cloudflare precisa che la regola esistente "PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619) #6" copre anche questo vettore, ma solo per i siti che usano il nome di campo predefinito per l'upload progress: chi ha personalizzato session.upload_progress.name non è coperto dalla regola WAF.

Cosa fare

Il WAF non sostituisce la patch. Chi gestisce server PHP in autonomia deve aggiornare alla versione corretta della propria branch; chi si appoggia a un hosting provider deve chiedere conferma dell'aggiornamento. Come mitigazione temporanea aggiuntiva, in attesa della correzione di CVE-2026-115560, vale la disattivazione di session.upload_progress.enabled nel php.ini o nel pool FPM, seguita dal riavvio di tutti i worker PHP.

Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).