PHP, nuova falla RCE PHP2Shell: disattiva subito questa funzione per proteggerti

Un’altra vulnerabilità di sicurezza interessa PHP, il linguaggio alla base di milioni di siti e applicazioni Web. Il 23 ottobre 2026, appena due giorni dopo la distribuzione degli aggiornamenti contro le falle critiche conosciute come PHP2Shell, il PHP Security Team ha pubblicato un nuovo avviso relativo alla falla di nuova scoperta contraddistinta dall’identificativo CVE-2026-115560 (ne abbiamo parlato nell’articolo sul bypass di ASLR da parte di PHP2Shell). Anche stavolta il rischio riguarda la possibile esecuzione di codice da remoto.

La scoperta arriva in una settimana particolarmente delicata per gli amministratori dei server PHP. Il 21 ottobre il progetto aveva rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per correggere CVE-2026-109618 e CVE-2026-109619, due vulnerabilità capaci di compromettere applicazioni esposte su Internet. La nuova segnalazione interessa invece una combinazione insolita tra gestione delle sessioni, serializzazione dei dati e monitoraggio del caricamento dei file.

Il dettaglio importante è che le patch del 21 ottobre non correggono CVE-2026-115560: per il momento, il team PHP raccomanda una misura temporanea che consiste nella disabilitazione della funzionalità session upload progress attraverso un parametro di configurazione. L’intervento è semplice, ma per applicarlo correttamente bisogna capire quando PHP elabora i dati ricevuti dal browser e quali componenti intervengono prima dell’esecuzione del codice applicativo.

Una terza vulnerabilità PHP dopo gli aggiornamenti contro PHP2Shell

Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 riguardano difetti interni del motore PHP e possono consentire attacchi anche senza autenticazione. Il secondo problema, in particolare, coinvolge la persistenza di uno stato interno non più valido tra richieste elaborate dallo stesso processo.

Per CVE-2026-115560, invece, il comunicato ufficiale del PHP Security Team descrive un percorso di attacco molto specifico, legato al modo in cui PHP gestisce i dati delle sessioni quando un’applicazione modifica, durante l’esecuzione, il formato utilizzato per salvarli e recuperarli.

Gli sviluppatori non hanno ritenuto necessario pubblicare immediatamente una nuova versione correttiva: la patch dovrebbe arrivare con il successivo aggiornamento ordinario, accompagnata da un advisory tecnico completo. Al 26 ottobre 2026, quindi, mancano ancora informazioni ufficiali sufficienti per ricostruire nei dettagli il meccanismo di sfruttamento e stabilire autonomamente una valutazione completa della gravità.

Il problema nasce prima che l’applicazione elabori il file caricato

Quando un utente carica un file mediante una richiesta HTTP multipart/form-data, il motore può registrare automaticamente nella sessione alcune informazioni sull’avanzamento del trasferimento.

Il meccanismo, descritto nella documentazione ufficiale di PHP, utilizza un campo del modulo chiamato normalmente PHP_SESSION_UPLOAD_PROGRESS. Durante il caricamento, PHP aggiorna una struttura associata a $_SESSION, registrando informazioni come la dimensione complessiva del trasferimento, i byte ricevuti e lo stato dell’operazione.

Un’applicazione può interrogare quei dati per costruire una barra di avanzamento lato server: la funzionalità è attiva per impostazione predefinita attraverso il parametro session.upload_progress.enabled, il cui valore standard è 1.

Il problema di fondo è che la gestione dell’upload avviene durante l’elaborazione iniziale della richiesta, prima che il normale codice PHP dell’applicazione possa intervenire. Non occorre nemmeno che lo script richiami esplicitamente session_start() affinché il monitoraggio dell’upload interagisca con i dati di sessione.

PHP può memorizzare le informazioni di sessione attraverso diversi formati. La vulnerabilità CVE-2026-115560 richiede una sequenza molto particolare: l’applicazione deve sapere in quale formato salvare i dati associati alle sessioni degli utenti e come interpretarli quando li recupera. A decidere il formato è la direttiva di configurazione session.serialize_handler, che può assumere, tra gli altri, i valori php, php_binary e php_serialize.

Come disabilitare session upload progress e proteggere PHP

La misura consigliata consiste nell’impostare il parametro session.upload_progress.enabled=0. In un file php.ini la direttiva da inserire, oppure da modificare se già presente, è la seguente:

session.upload_progress.enabled = 0

La posizione in cui applicare l’impostazione conta quanto il valore stesso. Poiché PHP elabora le informazioni degli upload prima di eseguire gli script applicativi, la modifica deve risultare effettiva già durante l’inizializzazione della richiesta.

Negli ambienti basati su PHP-FPM, un amministratore può intervenire nella configurazione del pool interessato, ad esempio nel relativo file www.conf, utilizzando quanto segue:

php_admin_value[session.upload_progress.enabled] = 0

Con Apache e mod_php, nei file di configurazione del server o del VirtualHost è possibile applicare:

php_admin_flag session.upload_progress.enabled off

Se Apache utilizza effettivamente mod_php e permette le relative direttive nei file .htaccess, è disponibile anche la sintassi php_flag session.upload_progress.enabled off. Nel caso di Apache collegato a PHP-FPM le direttive php_flag di mod_php non sono applicabili.

Come verificare se il server è esposto alla vulnerabilità

La verifica richiede due controlli differenti: il valore effettivo dell’opzione di upload progress e l’eventuale presenza di modifiche dinamiche al serializzatore.

Per individuare le configurazioni PHP caricate dalla versione utilizzata a riga di comando è utile eseguire php --ini. Il comando php -i permette inoltre di consultare il valore di session.upload_progress.enabled.

Attenzione, però: la configurazione della CLI (command-line interface) può essere diversa da quella utilizzata dal sito Web. Una verifica eseguita nel terminale non dimostra necessariamente che il pool PHP-FPM o il modulo Apache abbia recepito l’impostazione. È perciò molto meglio controllare il valore attraverso la stessa interfaccia PHP utilizzata dall’applicazione, mediante strumenti diagnostici protetti e accessibili soltanto agli amministratori.

Per analizzare il codice sorgente si può cercare la stringa session.serialize_handler nei file PHP dell’applicazione e nelle dipendenze. È opportuno individuare anche le chiamate a ini_set(), session_start() e le eventuali funzioni di inizializzazione delle sessioni.

Una ricerca testuale costituisce soltanto il primo livello di verifica: configurazioni generate dinamicamente, librerie esterne o richiami indiretti potrebbero sfuggire.

Disabilitare il monitoraggio interrompe il caricamento dei file?

No. Disattivare la direttiva session.upload_progress non impedisce il normale funzionamento delle richieste multipart/form-data, né elimina le funzionalità standard per ricevere e gestire i file tramite $_FILES.

L’effetto riguarda esclusivamente il meccanismo con cui PHP registra nella sessione lo stato dei trasferimenti: un’interfaccia che utilizza quei dati per mostrare la percentuale di caricamento potrebbe smettere di aggiornare la propria barra di avanzamento.

Molte applicazioni moderne sfruttano invece le funzionalità del browser, per esempio gli eventi progress associati a XMLHttpRequest, senza dipendere dalla sessione PHP: in tutti questi casi, la mitigazione non dovrebbe influire sull’indicatore di trasferimento.

Perché questa vulnerabilità va trattata con cautela

La falla CVE-2026-115560 evidenzia una caratteristica spesso sottovalutata dei linguaggi server: alcune operazioni avvengono automaticamente, prima che l’applicazione possa applicare i propri controlli. L’inizializzazione delle sessioni, l’elaborazione dei dati multipart e la scelta del serializzatore spesso non si snodano lungo fasi indipendenti.

Il tema è quindi rilevante per chi mantiene applicazioni PHP sviluppate nel corso di molti anni, magari con librerie che modificano impostazioni globali per ragioni di compatibilità. In simili situazioni un cambiamento apparentemente innocuo può produrre interazioni difficili da individuare con i normali test funzionali.

La decisione del PHP Security Team di rimandare la correzione al ciclo ordinario indica che il percorso di sfruttamento appare poco probabile, non che un’eventuale compromissione avrebbe conseguenze trascurabili.

Per gli amministratori la priorità è perciò mantenere aggiornato PHP rispetto alle vulnerabilità già corrette, verificare se il codice modifica dinamicamente session.serialize_handler e, dove opportuno, disabilitare il monitoraggio degli upload fino alla pubblicazione della patch specifica.