Questo pomeriggio, alle 16:00 ora italiana (le 14:00 UTC), il team di sicurezza di PHP pubblicherà una release straordinaria che corregge due vulnerabilità classificate come critiche, entrambe con un punteggio CVSS v4.0 di 9.2. Si tratta di un evento poco frequente, perché gli aggiornamenti di PHP arrivano di solito con un calendario mensile. Questa volta, invece, l’annuncio è stato diffuso, e il motivo è semplice: alcune informazioni sulle falle sono trapelate prima del previsto, insieme allo screenshot di uno strumento di attacco PHP2Shell.
I codici assegnati sono CVE-2026-109618 e CVE-2026-109619, e tutto lascia pensare a una esecuzione di codice remoto, cioè la possibilità per un estraneo di far girare comandi propri sul server. La questione riguarda molte più persone di quanto sembri. PHP è il linguaggio su cui poggiano WordPress, WooCommerce, Joomla, Drupal, Magento e una quantità enorme di pannelli e gestionali, quindi chi ha un piccolo negozio online o il sito di un’attività è coinvolto.
Cosa si sa delle due vulnerabilità
L’annuncio ufficiale è volutamente scarno. Dice che le falle sono due, che sono critiche, che la correzione arriva mercoledì 21 ottobre alle 14:00 UTC e che il team si riserva di anticipare il rilascio se comparissero attacchi reali. Le versioni coinvolte e quelle corrette, invece, saranno rese note soltanto con la release.
Secondo quanto circola da ieri sera, le falle toccherebbero il cuore di PHP e non un plugin o un singolo CMS. Lo screenshot dello strumento PHP2Shell dichiara di funzionare su ogni versione a partire da PHP 5.4, uscita nel 2012, e almeno una società di sicurezza ha confermato di aver riprodotto una delle due falle.
Alcuni ricercatori collocano il problema nella gestione dell’upload progress delle sessioni, la funzione che permette a PHP di tenere traccia dell’avanzamento di un caricamento di file, e parlano di un errore di memoria del tipo use-after-free. In parole semplici, il programma continua a usare uno spazio che ha già liberato, e un attaccante abile può sfruttare questo per inserire istruzioni proprie.
Perché una fuga di notizie cambia i tempi della patch
Nel mondo della sicurezza esiste una prassi chiamata divulgazione coordinata. Chi scopre una falla la segnala in privato agli sviluppatori, che preparano la correzione, la consegnano ai principali distributori di pacchetti e solo dopo la rendono pubblica insieme ai dettagli. In questo modo chi difende ha un vantaggio su chi attacca. Con PHP2Shell questo meccanismo si è inceppato a metà strada, perché le informazioni sono uscite prima che le patch fossero disponibili per tutti.
Nel momento in cui una correzione viene pubblicata, il codice sorgente modificato diventa leggibile da chiunque. Basta confrontare la nuova versione con quella precedente per individuare le righe cambiate e, da lì, ricostruire il punto debole. Si chiama patch diffing ed è un’operazione che un gruppo esperto completa in poche ore, a volte in pochi minuti se ha già indizi in mano. Per questo motivo il pomeriggio di oggi è il momento più delicato: i server aggiornati sono al riparo, quelli rimasti indietro diventano bersagli facili da trovare con scansioni automatiche.
C’è poi un secondo aspetto, meno evidente. Il codice sorgente arriva su php.net alle 16:00, ma quasi nessun server installa PHP direttamente da lì. La maggior parte riceve gli aggiornamenti tramite i pacchetti di Debian, Ubuntu e AlmaLinux, tramite le build di pannelli come cPanel e Plesk, oppure tramite le immagini Docker ufficiali. Ognuno di questi canali ha i propri tempi, e tra l’uscita della release e il pacchetto pronto sul proprio server possono passare da pochi minuti a diverse ore.
Come scoprire quale versione di PHP stai usando
Prima di intervenire serve sapere cosa c’è da aggiornare. Sembra banale, ma un solo server può ospitare più versioni di PHP contemporaneamente, e quella che risponde da terminale non sempre coincide con quella che serve le pagine web. Se hai accesso SSH, parti da questi comandi.
# versione usata da terminale
php -v
# file di configurazione caricati
php --ini
# versioni installate su Debian e Ubuntu
ls /etc/php/
# servizi PHP-FPM attivi
systemctl list-units --type=service 'php*-fpm*'
# stato della funzione indicata come possibile punto d'ingresso
php -i | grep session.upload_progress.enabled
PHP-FPM è il componente che esegue PHP per conto del server web in quasi tutte le installazioni moderne, e ogni versione ha un processo distinto. Se vedi più righe, annotale tutte, perché ciascuna andrà aggiornata e riavviata a parte, e dimenticarne una significa lasciare aperta proprio la porta che si voleva chiudere.
Se invece hai soltanto un hosting condiviso, il pannello di controllo mostra quasi sempre il ramo in uso in una voce chiamata “Versione PHP” o “Selettore PHP”. In alternativa puoi caricare via FTP un piccolo file con questo contenuto.
<?php
echo 'PHP ' . PHP_VERSION . '<br>';
echo 'upload_progress: ' . var_export(ini_get('session.upload_progress.enabled'), true);
Salvalo con un nome poco prevedibile, per esempio verifica-7f3k.php, aprilo dal browser e, appena letto il risultato, cancellalo. Lasciare file diagnostici sul server è una cattiva abitudine, soprattutto in una giornata come questa.
Il dato da annotare è il ramo principale, cioè le prime due cifre. Oggi PHP mantiene con aggiornamenti di sicurezza soltanto i rami 8.2, 8.3, 8.4 e 8.5, mentre la 8.6 è ancora in fase di test. Le ultime versioni pubblicate il 24 settembre sono 8.2.34, 8.3.35, 8.4.26 e 8.5.11, quindi qualunque numero precedente indica che sei già indietro di almeno un ciclo di correzioni.
La misura temporanea che circola e i suoi limiti
In attesa della release, si sta diffuondendo un rimedio provvisorio: disattivare la funzione session.upload_progress. È attiva per impostazione predefinita, ma quasi nessun sito la usa, perché serve soltanto a mostrare barre di avanzamento durante l’invio dei file. WordPress, per esempio, non ne ha bisogno per inserire immagini nella libreria media.
Su un server che gestisci tu, il modo più pulito è creare un piccolo file di configurazione aggiuntivo, così da non modificare il php.ini principale e poterlo rimuovere facilmente dopo l’aggiornamento. L’esempio usa PHP 8.3 su Debian o Ubuntu, quindi adatta il numero alla tua versione.
echo "session.upload_progress.enabled = Off" | sudo tee /etc/php/8.3/fpm/conf.d/99-php2shell.ini
sudo systemctl restart php8.3-fpm
# verifica dalla configurazione FPM
php-fpm8.3 -i | grep session.upload_progress.enabled
Se usi Apache con il modulo PHP integrato (mod_php), il percorso diventa /etc/php/8.3/apache2/conf.d/ e il servizio da riavviare è apache2. Sugli hosting condivisi, invece, la stessa impostazione si può inserire in un file .user.ini nella radice del sito.
session.upload_progress.enabled = 0
Questa direttiva rientra tra quelle modificabili per cartella, quindi il file .user.ini funziona, mentre una chiamata a ini_set() dentro il codice del sito non avrebbe alcun effetto. Tieni presente che PHP rilegge questo file ogni cinque minuti circa, perciò il cambiamento non è istantaneo. Ricontrolla poi con il file di verifica visto prima.
Tuttavia, si tratta di un’indicazione non ufficiale, basata su indiscrezioni, e nessuno può garantire oggi che copra entrambe le vulnerabilità. Vale come cintura di sicurezza per le ore che mancano alla patch, o per i server che riceveranno il pacchetto in ritardo, non come sostituto dell’aggiornamento.
Aggiornare PHP su Debian, Ubuntu, pannelli e Docker
Quando la release esce, la prima cosa da fare è leggere l’avviso ufficiale per capire quali rami sono coinvolti e con che numeri di versione arriva la correzione. Seguendo la numerazione abituale ci si aspettano le 8.2.35, 8.3.36, 8.4.27 e 8.5.12, ma è un’ipotesi e conviene verificarla. Subito dopo si passa alla pratica, e la procedura cambia a seconda di come PHP è arrivato sul server.
Su Debian e Ubuntu con i pacchetti del sistema o con il repository di terze parti più diffuso (quello di Ondřej Surý), la sequenza è questa.
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
# controlla che il pacchetto citi le nuove CVE
apt changelog php8.3-common | head -20
Un dettaglio importante riguarda la numerazione. Le distribuzioni ufficiali spesso applicano la correzione alla versione che già offrono senza cambiare il numero principale, quindi php -v potrebbe mostrare una cifra apparentemente vecchia anche su un sistema già protetto. In questi casi la prova sta nel changelog del pacchetto, cioè l’elenco delle modifiche, non nel numero.
Su AlmaLinux, Rocky Linux e affini con il repository Remi il comando è sudo dnf upgrade 'php*', seguito dal riavvio di php-fpm. Sui server cPanel le versioni EasyApache ricevono la patch con sudo dnf update 'ea-php*', mentre Plesk distribuisce le proprie build tramite l’apposita sezione del pannello.
Per Docker, invece, non basta far ripartire il container. Bisogna scaricare la nuova immagine e ricostruire la propria senza usare la cache.
docker pull php:8.4-fpm
docker build --pull --no-cache -t mio-sito:patch .
docker run --rm mio-sito:patch php -v
L’ultimo passaggio è il più trascurato. Dopo ogni riavvio apri almeno una pagina reale del sito e verifica che si carichi correttamente, poi rimuovi il file temporaneo 99-php2shell.ini soltanto dopo che l’avviso ufficiale avrà chiarito se quell’impostazione è coinvolta.
Chi è rimasto su PHP 7 o 8.1 resta senza protezione
PHP pubblica correzioni soltanto per i rami ancora mantenuti, e oggi sono quattro, dalla 8.2 alla 8.5. La 8.1, la 8.0 e tutta la serie 7.x sono fuori supporto, quindi se le indiscrezioni sulla compatibilità di PHP2Shell con le release più datate fossero confermate, quei server non riceveranno alcuna patch da php.net. Il problema non è teorico, perché in rete girano ancora molti siti su PHP 7.4, spesso dimenticati da anni.
Qualche distribuzione con supporto esteso, alcune offerte commerciali e certi pannelli di hosting applicano correzioni anche a rami vecchi, ma lo fanno con tempi propri e senza garanzie. Contare su questa eventualità, oggi, è una scommessa.
La soluzione vera è il passaggio a un ramo supportato. Non è un semplice aggiornamento di pacchetto, perché temi, plugin e codice personalizzato possono usare funzioni che le versioni recenti di PHP hanno rimosso o modificato. Per un sito WordPress il percorso ragionevole è questo.
- Backup completo. File e database, conservati fuori dal server.
- Aggiornamento del CMS, dei temi e dei plugin. Le versioni recenti sono quasi sempre già compatibili con PHP 8.3 e 8.4.
- Collaudo in un ambiente separato. Molti hosting offrono uno staging, cioè un duplicato del sito su cui fare esperimenti, attivabile con un clic.
- Cambio di versione dal pannello. Poi controllo del sito pagina per pagina.
Conviene puntare almeno alla 8.4. La 8.2 riceverà correzioni di sicurezza solo fino al 31 dicembre 2026, quindi fermarsi lì significherebbe rifare lo stesso lavoro tra un paio di mesi. Nel frattempo, se la migrazione richiede giorni, la disattivazione dell’upload progress e un firewall applicativo davanti al sito sono il minimo indispensabile.
Tra php.net e il tuo server c’è una catena da sorvegliare
Una falla critica in un componente così diffuso non è un caso isolato, e PHP sta gestemdo la situazione in modo corretto, con un preavviso chiaro e una data precisa. La parte difficile, però, sta nella catena che porta la correzione fino al tuo server, fatta di distribuzioni, provider, pannelli e immagini Docker, ognuno con i propri tempi.
Se gestisci un server, organizza già da ora chi farà l’aggiornamento e quando. Se hai un sito su hosting condiviso, scrivi al provider, nel dubbio, applica la misura temporanea con il file .user.ini. Se sei ancora su PHP 7 o 8.1, considera questa giornata come l’ultimo segnale utile per una migrazione rimandata troppo a lungo. Resta un’incognita importante, cioè la reale estensione delle versioni coinvolte, che si chiarirà soltanto con l’avviso ufficiale.
