Il 21 ottobre il progetto PHP ha pubblicato le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Correggono due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, chiamate php2shell, che permettono di eseguire codice su un server senza login. Se il tuo sito gira su PHP, cioè WordPress, WooCommerce, Joomla, Drupal, Magento o un gestionale scritto in PHP, oggi devi scoprire se il PHP del tuo server è già corretto. Aggiornare WordPress e i plugin non basta: la falla sta nel linguaggio, sotto il sito.
Cosa fanno le due falle
La prima, CVE-2026-109618, scatta quando PHP esaurisce la memoria concessa a una richiesta. Se succede in un punto preciso, PHP chiude la richiesta leggendo memoria in uno stato non valido, e per provocarlo basta un invio di file costruito apposta. Secondo l'avviso del progetto, con Apache e mod_php l'esecuzione di codice è stata dimostrata con le impostazioni predefinite, prima che parta una sola riga dell'applicazione.
CVE-2026-109619 invece sfrutta il fatto che un processo PHP serve una richiesta dopo l'altra. Una richiesta lascia un riferimento a memoria che non le appartiene più, e quella dopo, arrivata allo stesso processo, lo usa. La strada è il meccanismo che registra l'avanzamento dei caricamenti nelle sessioni, attivo di default anche se il sito non apre nessuna sessione. L'avviso conferma l'esecuzione di codice sia con mod_php sia con PHP-FPM.
Chi rischia di più
Il progetto PHP considera esposta qualunque installazione che serve pagine web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed. Il rischio più alto è con mod_php. Con PHP-FPM, la configurazione più diffusa negli hosting recenti, la prima falla è più difficile da sfruttare: Red Hat spiega che i processi di FPM si chiudono prima di arrivare alla memoria corrotta. La seconda però funziona anche lì, quindi chi è su FPM aggiorna oggi come gli altri.
Quanto è grave adesso
Sullo sfruttamento reale le fonti non sono d'accordo. Amazon ha registrato nei suoi server esca un tentativo il 17 ottobre, quattro giorni prima della divulgazione, e scrive che php2shell è ora «ampiamente sfruttato», anche se non sa dire se quei tentativi sarebbero riusciti su sistemi veri. Sansec, in un aggiornamento del 22 ottobre, ritiene invece meno probabile del previsto uno sfruttamento di massa, perché gli exploit pubblici non funzionano su un PHP con le impostazioni predefinite. La CISA il 21 non aveva osservato sfruttamenti, e al 22 ottobre le due CVE non compaiono nel suo catalogo delle vulnerabilità sfruttate.
Per noi è urgente lo stesso. Chi ha trovato le falle ha exploit che funzionano, e il 20 ottobre ne è uscito per errore un video, tanto che il rilascio è stato anticipato di un giorno (PHP Foundation). Per prendere il server non serve nessuna credenziale. Non aspetteremmo di sapere chi fra Amazon e Sansec ha ragione.
Il numero di versione può ingannare
Molti hosting non installano le versioni nuove del progetto: riportano la correzione dentro la versione che hai già, e il numero resta uguale. CloudLinux, usato da moltissimi hosting condivisi, lo scrive in chiaro: cambia il rilascio del pacchetto, la versione di PHP no, quindi si controlla il registro delle modifiche. Plesk ha corretto anche 7.4.33, 8.0.30 e 8.1.34, che mantengono il numero ma contengono la correzione se compilate dal 21 ottobre 2026. cPanel l'ha distribuita per tutti i suoi PHP, dal 7.4 all'8.5, con EasyApache 4 del 21 ottobre. Molte distribuzioni Linux fanno lo stesso.
Un sito che dichiara PHP 8.1.34 può quindi essere corretto, e uno che dichiara 8.3.36 può non esserlo, se dopo l'aggiornamento nessuno ha riavviato i processi. Per saperlo guardi la data di compilazione (php -v la mostra) o il registro delle modifiche del pacchetto, oppure ti fai rispondere per iscritto dall'hosting.
Cosa fare oggi
- Trova la versione di PHP del sito e come gira (mod_php, PHP-FPM, LiteSpeed). Nel pannello dell'hosting sta di solito alla voce PHP; sul server,
php -vmostra versione e data di compilazione. - Se sei su un hosting condiviso, scrivi all'hosting con il messaggio qui sotto.
- Se il server è tuo, aggiorna i pacchetti di PHP, controlla che il registro delle modifiche citi CVE-2026-109618 e CVE-2026-109619 e riavvia tutti i processi PHP: Apache, PHP-FPM, LiteSpeed. Finché girano i processi vecchi, il pacchetto nuovo resta sul disco e basta.
- Se oggi non puoi aggiornare, applica le misure temporanee descritte più avanti.
- Guarda i log dal 17 ottobre in poi, anche se hai già aggiornato, come raccomanda lo CSIRT Italia. Secondo Sansec tutti i percorsi d'attacco noti passano da richieste di invio file (
multipart/form-data): se ne trovi verso pagine senza moduli, insieme a errori di memoria esaurita o processi PHP chiusi di colpo, copia log e file prima di toccare qualunque cosa.
Il messaggio per l'hosting, da adattare:
Buongiorno, il sito [dominio] è ospitato sul vostro piano [nome del piano]. Vi chiedo conferma scritta che la versione di PHP in uso includa le correzioni per CVE-2026-109618 e CVE-2026-109619 (php2shell), pubblicate il 21 ottobre 2026, e che i processi PHP siano stati riavviati dopo l'aggiornamento. Se non è ancora così, quando è previsto l'intervento? Grazie.
Le misure temporanee, se non puoi aggiornare
Il progetto PHP le presenta per quello che sono: chiudono alcuni percorsi d'attacco e lasciano aperti gli altri. Vanno nella configurazione del server o del pool di FPM, non in un .user.ini né con ini_set(), perché devono valere prima che PHP legga la richiesta:
memory_limit=-1, impostato in modo che l'applicazione non possa cambiarlo, per esempio conphp_admin_valuepost_max_size = 8M, oppure32Mse il sito riceve file, conupload_max_filesizepiù bassosession.upload_progress.enabled=0, poi riavvio di tutti i processi- su PHP 8.5, anche
fatal_error_backtraces=0
Senza limite di memoria una sola richiesta pesante può prendersi tutta la RAM, quindi serve un tetto a livello di container o di sistema. I ricercatori di watchTowr ritengono queste modifiche inefficaci per impedire lo sfruttamento. Il firewall di Cloudflare ha regole attive dal 21 ottobre per tutti i clienti che lo usano, piano gratuito compreso, ma un firewall ferma le forme di attacco che conosce. Noi queste misure le useremmo solo per coprire le ore che mancano all'aggiornamento.
Se il sito gira su PHP 8.1 o più vecchio
Il 12 ottobre abbiamo scritto che PHP 8.2 resta senza correzioni di sicurezza dal 1° gennaio. Nove giorni dopo 8.2 ha avuto la sua correzione; dal 2027 non ne riceverà più.
Per 8.1, 8.0 e 7.4 il progetto PHP non ha pubblicato nessuna nuova versione, solo correzioni minime del sorgente per chi compila PHP da sé, e rimanda alle distribuzioni e ai fornitori con supporto esteso. In pratica, su queste versioni sei coperto solo se il tuo hosting usa CloudLinux, Plesk, cPanel o una distribuzione con supporto esteso e ha installato la loro correzione. Per i siti che non si possono aggiornare subito, lo CSIRT Italia raccomanda di valutare di metterli offline finché non sono corretti, e la CISA scrive di spegnerli.
Il messaggio all'hosting è lo stesso. Se la risposta è no, o non arriva, la migrazione a una versione supportata è il lavoro di questa settimana.
Se non sai quale PHP usa il tuo sito, o l'hosting non risponde, scrivici. Guardiamo come gira PHP sul tuo server, ti diciamo se sei esposto e, se sei su una versione fuori supporto, quanto lavoro serve per spostare il sito su una versione corretta.