ALLARME PHP: CVE-2026-115560, nuova RCE senza patch dopo l’emergenza PHP2Shell

🛡️ Executive Summary

• PHP segnala una nuova vulnerabilità RCE, CVE-2026-115560, il 23 ottobre 2026, due giorni dopo le patch di emergenza per PHP2Shell. La correzione definitiva arriverà nel normale ciclo di aggiornamento.
• Lo sfruttamento richiede una combinazione insolita di configurazione e codice applicativo: il cambio dinamico di session.serialize_handler da php_binary o php_serialize a php, con la funzione session upload progress attiva.
• La mitigazione ufficiale consiste nel disabilitare session.upload_progress.enabled prima dell’elaborazione delle richieste. Chi aveva già applicato questa misura contro CVE-2026-109619 non deve ripeterla.

PHP torna a segnalare una vulnerabilità di esecuzione remota di codice appena due giorni dopo aver distribuito le patch di emergenza contro PHP2Shell. Il 23 ottobre 2026 il team di sicurezza del linguaggio ha pubblicato un nuovo avviso relativo a CVE-2026-115560, una debolezza ancora priva di correzione definitiva che coinvolge la gestione delle sessioni durante il caricamento dei file. A differenza delle due vulnerabilità critiche divulgate il 21 ottobre, il nuovo problema richiede una combinazione molto specifica di configurazione del server e comportamento dell’applicazione. Gli sviluppatori non hanno annunciato un ulteriore aggiornamento straordinario, preferendo rimandare la patch alla prossima release ordinaria e raccomandando nel frattempo di disabilitare la funzionalità session upload progress. La distinzione è fondamentale: l’avviso conferma l’esistenza di un ulteriore percorso potenziale di compromissione, ma non dimostra che tutti i server PHP aggiornati siano nuovamente esposti a una RCE generalizzata.

PHP identifica CVE-2026-115560 dopo le due falle critiche PHP2Shell

Il nuovo avviso compare nel bollettino ufficiale PHP del 23 ottobre 2026, pubblicato con il titolo Informational advisory: Session upload progress. Gli sviluppatori spiegano che la vulnerabilità può teoricamente consentire l’esecuzione remota di codice, ma soltanto quando vengono soddisfatte precise condizioni di configurazione. Per questo motivo PHP non attribuisce ancora pubblicamente al problema un punteggio CVSS definitivo e rimanda la pubblicazione dell’advisory tecnico completo alla prossima release correttiva. Il codice identificativo assegnato è CVE-2026-115560, distinto da CVE-2026-109618 e CVE-2026-109619, le due falle PHP2Shell corrette il 21 ottobre attraverso le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

La tempistica rende il nuovo avviso particolarmente rilevante, perché arriva durante una fase di aggiornamenti straordinari che ha interessato milioni di installazioni PHP e numerosi fornitori di servizi web. Le precedenti vulnerabilità, ricostruite nell’analisi sulle patch PHP2Shell e sui rischi per i server applicativi, riguardavano errori nella gestione della memoria capaci di consentire l’esecuzione di codice senza autenticazione. CVE-2026-115560 presenta invece requisiti applicativi specifici, che ne limitano il perimetro rispetto all’emergenza precedente. Le due vicende condividono tuttavia un elemento: il coinvolgimento delle strutture interne utilizzate da PHP per gestire richieste HTTP e sessioni.

Leggi anche: PHP2Shell attaccato prima delle patch: emergono i primi tentativi di exploit

La vulnerabilità nasce dal cambio dinamico del gestore delle sessioni

Il meccanismo descritto dal team PHP riguarda session.serialize_handler, direttiva che determina come vengono serializzati e deserializzati i dati conservati nelle sessioni. PHP supporta diverse modalità, tra cui php, php_binary e php_serialize, che utilizzano rappresentazioni differenti delle informazioni. La vulnerabilità emerge quando un’applicazione parte con session.serialize_handler configurato su php_binary oppure php_serialize, modifica successivamente il valore a php utilizzando la funzione ini_set() e soltanto dopo esegue session_start(). A questa sequenza deve aggiungersi un’ulteriore condizione: session.upload_progress.enabled deve risultare attivo.

La concatenazione dei requisiti rappresenta il motivo per cui il progetto considera improbabile lo sfruttamento nella maggior parte delle installazioni. Non basta utilizzare sessioni PHP, consentire upload o eseguire WordPress, Drupal o Joomla: l’applicazione deve seguire il particolare percorso di configurazione indicato dagli sviluppatori. Un sito che utilizza il serializzatore predefinito senza modificarlo dinamicamente non soddisfa i requisiti descritti. Il progetto chiarisce infatti che le applicazioni che non cambiano il gestore di serializzazione durante l’esecuzione possono mantenere attiva la funzione di monitoraggio dei caricamenti. Ciò non significa che ogni applicazione sia sicura per definizione, ma permette di indirizzare le verifiche verso il codice effettivamente interessato anziché trattare indiscriminatamente tutti gli ambienti PHP come vulnerabili.

Il problema conferma l’importanza delle condizioni di inizializzazione del runtime, già evidenziata negli approfondimenti sulle vulnerabilità critiche PHP e sull’esecuzione di codice remoto nei server web. Una configurazione apparentemente innocua può diventare pericolosa quando viene modificata durante una fase particolare dell’elaborazione della richiesta, soprattutto se componenti differenti conservano o interpretano lo stato in modi incompatibili.

PHP raccomanda di disabilitare session.upload_progress.enabled

La misura di contenimento indicata dal progetto è precisa: impostare session.upload_progress.enabled=0 fino alla distribuzione della correzione definitiva. La direttiva controlla una funzionalità attraverso la quale PHP registra nella sessione informazioni relative all’avanzamento dei file caricati mediante richieste HTTP. La documentazione ufficiale Session Upload Progress chiarisce che questa funzione permette a un’applicazione di interrogare periodicamente lo stato di un caricamento e recuperare informazioni sul numero di byte già elaborati. Non è necessaria per tutti i siti che accettano file: serve specificamente alle applicazioni che utilizzano il meccanismo nativo PHP per monitorare l’avanzamento dell’upload.

La configurazione raccomandata è:

session.upload_progress.enabled = 0

La modifica deve essere applicata nella configurazione effettivamente utilizzata dal server web, ad esempio attraverso php.ini o una configurazione amministrativa del pool PHP-FPM, e deve essere accompagnata dal riavvio o riciclo dei processi interessati. Nel precedente advisory PHP relativo a CVE-2026-109619 gli sviluppatori avevano già specificato che la disattivazione va applicata prima dell’elaborazione della richiesta, evitando di affidarsi a modifiche tardive attraverso ini_set() o a impostazioni .user.ini che non garantiscano il controllo richiesto. Chi aveva già disabilitato session upload progress durante l’emergenza del 21 ottobre risulta già protetto dal nuovo percorso segnalato, secondo quanto dichiara il progetto PHP.

La disattivazione può influire sulle applicazioni che utilizzano espressamente questa funzionalità per mostrare l’avanzamento dei caricamenti. Gli amministratori devono quindi verificare eventuali dipendenze applicative, senza confondere la disabilitazione del monitoraggio nativo con il blocco generale dell’upload dei file. La misura interviene sulla funzionalità di tracciamento delle sessioni, non sul normale funzionamento di tutte le operazioni di caricamento.

Come verificare i server WordPress e le applicazioni PHP

Per gli amministratori di sistemi PHP, la nuova segnalazione rende necessario distinguere due attività. La prima consiste nel verificare che siano state realmente applicate le correzioni contro CVE-2026-109618 e CVE-2026-109619, poiché la configurazione suggerita oggi non sostituisce quelle patch. La seconda riguarda l’individuazione delle applicazioni che modificano dinamicamente il gestore delle sessioni. Occorre esaminare il valore effettivo di session.serialize_handler, cercare nel codice chiamate a ini_set() che intervengano sulla direttiva e verificare se l’applicazione utilizzi session.upload_progress.enabled. L’analisi deve comprendere anche dipendenze, plugin e componenti applicativi personalizzati, perché la modifica del serializzatore potrebbe non comparire direttamente nel codice principale.

La verifica merita particolare attenzione negli ambienti di hosting condiviso, dove la versione PHP visibile dal pannello di controllo e le impostazioni amministrative effettivamente caricate da PHP-FPM possono differire. Lo stesso principio è stato ribadito dal CERT-AGID nelle indicazioni sugli strumenti di verifica PHP2Shell: conoscere il numero di versione dell’interprete non è sempre sufficiente per descrivere la configurazione realmente utilizzata dal servizio web. Nel caso della nuova vulnerabilità, uno scanner basato esclusivamente sulle versioni potrebbe risultare ancora meno indicativo, perché l’esposizione dipende dal comportamento dell’applicazione e dalle direttive attive durante l’esecuzione.

Non risultano nel comunicato PHP del 23 ottobre indicatori pubblici di compromissione, exploit funzionanti distribuiti o campagne di attacco attribuite specificamente a CVE-2026-115560. Le statistiche relative ai milioni di tentativi osservati contro PHP2Shell non possono quindi essere trasferite alla nuova vulnerabilità, così come non possono essere utilizzate per sostenere che questa sia già sfruttata attivamente. Il contesto resta quello di una superficie tecnologica molto diffusa, nel quale è necessario distinguere rischio potenziale, presenza dei requisiti di configurazione e compromissione effettiva.

Continua con:

PHP2Shell, due falle critiche da 9,2: aggiornamento di emergenza per PHP

La terza CVE PHP non riapre automaticamente l’emergenza globale

CVE-2026-115560 non annulla le correzioni distribuite il 21 ottobre, ma dimostra che la revisione del ciclo di gestione delle sessioni PHP non si è conclusa con la pubblicazione delle due patch di emergenza. Il progetto ha scelto di rendere pubblica la condizione vulnerabile prima della disponibilità della correzione definitiva, indicando una mitigazione immediata e verificabile. La decisione riflette una valutazione tecnica differente rispetto a PHP2Shell: la vulnerabilità richiede condizioni insolite, la funzione coinvolta può essere disabilitata e non è stata giudicata necessaria una nuova release fuori programma. La lezione operativa per amministratori, sviluppatori e fornitori di hosting consiste nel non confondere l’aggiornamento del runtime con la sicurezza complessiva della configurazione. Le versioni corrette per PHP2Shell restano obbligatorie, ma la nuova segnalazione richiede anche un controllo delle direttive di sessione e del comportamento applicativo. Fino alla prossima release, disabilitare il monitoraggio nativo dell’avanzamento degli upload costituisce la soluzione prudenziale consigliata da PHP. L’episodio conferma soprattutto che la superficie di attacco di un linguaggio non dipende soltanto dai bug nel codice sorgente, ma anche dalle interazioni tra funzioni legittime, configurazioni differenti e sequenze di esecuzione difficili da prevedere.