Il 21 ottobre 2026 sono state rese pubbliche due falle nel cuore di PHP, il linguaggio su cui girano WordPress, Laravel e buona parte del web. I codici sono CVE-2026-109618 e CVE-2026-109619 (le CVE sono le sigle con cui si catalogano le vulnerabilità); in rete le hanno chiamate php2shell.
Gravità 9.2 nella scala CVSS 4.0. Permettono di eseguire codice sul server da remoto, senza fare login. In pratica chi le sfrutta può comandare la macchina come se fosse sua.
Cosa è successo quel giorno
Le correzioni ufficiali sono uscite lo stesso giorno: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Nelle stesse ore giravano già sfruttamenti reali, quindi aspettare il mattino dopo era fuori discussione.
Cloudflare ha esteso anche ai piani gratuiti le regole del suo WAF, il firewall applicativo che esamina le richieste prima che arrivino al sito. Con un avvertimento onesto: gli attaccanti modificano gli attacchi per aggirare le regole, quindi il filtro aiuta ma da solo non basta.
Il nostro problema: l'aggiornamento non c'era
I nostri server usano CloudLinux con cPanel, che distribuisce PHP con pacchetti propri. La sera del 21 la versione corretta di quei pacchetti non era ancora uscita.
Sui server giravano cinque versioni di PHP-FPM, il servizio che esegue PHP per i siti: 7.4, 8.2, 8.3, 8.4 e 8.5. Abbiamo lavorato su due fronti.
1. Chiudere la via d'attacco confermata
La via d'attacco confermata passa da session.upload_progress, una funzione di PHP che tiene traccia dell'avanzamento dei caricamenti di file. L'abbiamo spenta su tutte le versioni installate, con un file di configurazione dedicato e un riavvio di PHP-FPM:
for d in /opt/cpanel/ea-php*/root/etc/php.d; do
echo "session.upload_progress.enabled = 0" > $d/zz-php2shell.ini
done
/scripts/restartsrv_apache_php_fpmIl ciclo passa da ogni versione di PHP presente sul server, così nessuna resta indietro. Va detto chiaro: questa mitigazione chiude la via d'attacco confermata, non tutte quelle possibili. Era un tampone in attesa della correzione vera.
2. Il filtro davanti
I nostri server accettano sulle porte web solo traffico che arriva da Cloudflare. Chi prova a colpire un sito puntando dritto al server trova la porta chiusa, quindi le nuove regole del WAF si applicavano a ogni singola richiesta.
Una correzione con lo stesso numero di versione
CloudLinux ha rilasciato i pacchetti corretti alle 22:55 ora italiana, con un dettaglio che poteva trarre in inganno: il numero di versione di PHP non è cambiato.
La 8.5.11 è rimasta 8.5.11, ma il pacchetto è diventato 8.5.11-2.el9.cloudlinux.1. Lo stesso per la 8.4.26, diventata 8.4.26-2…cloudlinux.1, e per la 7.4.33, passata a 7.4.33-18…cloudlinux.13.
Chi guardava solo il numero di versione vedeva 8.5.11 prima e dopo, e non poteva sapere se era protetto. Bisognava leggere la revisione del pacchetto.
La mattina dopo
Abbiamo aggiornato i pacchetti e controllato le revisioni su ogni server con un comando:
rpm -qa 'ea-php*-php-cli' | sortIl criterio era semplice. Ogni riga deve finire in .cloudlinux.1, quella della 7.4 in .cloudlinux.13. Una riga diversa vuol dire un PHP ancora da aggiornare.
Il file di mitigazione l'abbiamo lasciato al suo posto. Con la correzione installata fa da seconda cintura, e ai siti non dà alcun fastidio.
Cosa ci portiamo a casa
- Su un server con più versioni di PHP la correzione va applicata a tutte, compresa la 7.4 che ancora serve a qualche sito.
- Quando la correzione tarda, una mitigazione mirata e un filtro davanti fanno guadagnare le ore necessarie.
- Per sapere se si è protetti si guarda il pacchetto installato, e non l'annuncio.
