CVE-2026-115560: Nuovo rischio di RCE PHP non patchato che richiede mitigazione immediata

PHP ha divulgato CVE-2026-115560, un nuovo rischio di esecuzione di codice remoto che colpisce le applicazioni web che utilizzano una combinazione insolita di configurazione delle sessioni PHP e comportamento in esecuzione. Il problema è stato divulgato il 23 ottobre 2026, solo due giorni dopo che PHP ha rilasciato correzioni di emergenza per le vulnerabilità critiche PHP2Shell CVE-2026-109618 e CVE-2026-109619.

A differenza di quelle vulnerabilità precedenti, CVE-2026-115560 non ha provocato un altro rilascio di emergenza di PHP. Il team di sicurezza PHP considera improbabile la configurazione vulnerabile nelle distribuzioni tipiche e prevede di affrontare il difetto attraverso il prossimo ciclo di correzioni regolari. Fino ad allora, si consiglia agli amministratori di disabilitare la funzione di progresso del caricamento delle sessioni PHP laddove potrebbe esistere la configurazione vulnerabile.

La nuova vulnerabilità è importante anche perché l’installazione di PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35—le versioni che hanno corretto i due difetti PHP2Shell precedenti— not non risolve CVE-2026-115560. I sistemi completamente aggiornati potrebbero quindi rimanere esposti se le loro applicazioni soddisfano i prerequisiti di configurazione specifici.

I team di sicurezza che cercano opportunità di rilevamento di CVE-2026-115560 dovrebbero dare priorità alla visibilità nella gestione delle sessioni PHP, caricamenti multipart insolitamente, cambiamenti inaspettati nel comportamento della serializzazione delle sessioni e processi figli sospetti generati da PHP o dai lavoratori del server web.

La Piattaforma di Intelligenza di Rilevamento AI-Native di SOC Prime consente ai team di sicurezza di rafforzare la copertura per l’esploitazione di vulnerabilità emergenti e il comportamento post-compromissione associato in ambienti SIEM, EDR e Data Lake.

Clicca Esplora Rilevamenti per accedere ai contenuti di rilevamento pertinenti e alla logica di caccia. Per rilevare CVE-2026-115560, i difensori dovrebbero combinare l’assessment della configurazione PHP con la telemetria web, endpoint, applicazione e proxy inverso mentre una patch del fornitore rimane non disponibile.

I professionisti della sicurezza possono anche sfruttare Prime Architect per trasformare l’intelligenza delle vulnerabilità di recente divulgazione in regole Sigma e query di caccia, validare la logica di rilevamento e tradurre i rilevamenti pertinenti su piattaforme di sicurezza supportate.

Contatta le Vendite

Analisi di CVE-2026-115560

PHP ha pubblicato un avviso informativo il 23 ottobre descrivendo un’interazione potenzialmente sfruttabile tra la serializzazione delle sessioni e la funzione di progresso del caricamento delle sessioni.

Secondo il team di sicurezza PHP, un’applicazione deve soddisfare diverse condizioni specifiche affinché il problema possa verificarsi:

• session.serialize_handler deve essere inizialmente configurato come php_binary o php_serialize.
• Il codice dell’applicazione deve successivamente cambiare il gestore in php durante l’esecuzione utilizzando ini_set().
• Quel cambiamento deve avvenire prima che session_start() venga chiamato.
• session.upload_progress.enabled deve rimanere abilitato.

Le applicazioni che non cambiano mai il gestore di serializzazione durante l’esecuzione non sono esposte attraverso questo percorso specifico e possono continuare a utilizzare il progresso del caricamento delle sessioni. PHP descrive la combinazione vulnerabile come non comune.

Questa distinzione riduce notevolmente la superficie di attacco rispetto a CVE-2026-109618 e CVE-2026-109619. Le precedenti vulnerabilità PHP2Shell hanno colpito ampiamente le installazioni PHP server web e hanno richiesto aggiornamenti di emergenza. CVE-2026-115560 invece dipende dalla configurazione specifica delle applicazioni e dal comportamento del codice.

I dettagli di CVE-2026-115560 rimangono intenzionalmente limitati. PHP non ha ancora pubblicato la causa tecnica completa, gli intervalli di versione esatti vulnerabili, un punteggio CVSS o la transizione specifica dello stato della memoria o della sessione interno che produce infine la condizione RCE. Il fornitore afferma che quei dettagli saranno inclusi con il prossimo rilascio regolare.

Sulla base dei prerequisiti divulgati, la vulnerabilità sembra collegata a una gestione incoerente dei dati di sessione quando un’applicazione cambia i formati di serializzazione durante l’elaborazione delle richieste mentre il meccanismo di avanzamento del caricamento di PHP è attivo. Tuttavia, la primitiva di sfruttamento esatta non dovrebbe essere dedotta oltre quanto PHP ha formalmente dichiarato.

CVE-2026-115560 colpisce le applicazioni che soddisfano il modello di configurazione vulnerabile, incluse le applicazioni che eseguono versioni PHP completamente patchate contenenti le correzioni PHP2Shell del 21 ottobre. PHP non ha ancora indicato quali rami di PHP o versioni storiche contengano il difetto sottostante.

Ciò significa che gli amministratori non dovrebbero determinare l’esposizione unicamente dalla versione PHP installata. Invece, devono valutare la configurazione dell’applicazione e del server.

Un primo passo utile è verificare se il progresso del caricamento delle sessioni è abilitato:

session.upload_progress.enabled=1

Gli amministratori dovrebbero anche identificare qualsiasi codice applicativo che chiama ini_set() per modificare session.serialize_handler, in particolare le transizioni da php_binary o php_serialize a php.

Il nuovo difetto è separato da CVE-2026-109619 anche se la mitigazione si sovrappone. Disabilitare il progresso del caricamento delle sessioni era già raccomandato come misura di riduzione del rischio per una delle vulnerabilità originali PHP2Shell. Le organizzazioni che hanno mantenuto quella impostazione disabilitata dopo l’aggiornamento di emergenza del 21 ottobre sono già protette contro il percorso di recente divulgazione, secondo PHP.

Attualmente non esiste alcun PoC pubblico per CVE-2026-115560 documentato da PHP o dai due rapporti forniti. Il team di sicurezza non ha inoltre divulgato informazioni tecniche sufficienti per riprodurre la vulnerabilità in modo affidabile dall’avviso pubblico da solo.

Ciò è in modo particolare diverso dalle falle PHP2Shell precedenti, per le quali sono emersi diversi tentativi di proof-of-concept e attività di exploit attorno alla divulgazione. Quegli attacchi non dovrebbero essere attribuiti alla nuova vulnerabilità.

Nessuno sfruttamento di CVE-2026-115560 è stato segnalato al 26 ottobre 2026. The Hacker News distingue specificamente le scansioni PHP2Shell in corso e i tentativi di sfruttamento da questa nuova vulnerabilità, notando che l’attività osservata prende di mira CVE-2026-109618 e CVE-2026-109619.

Di conseguenza, gli IOCs di CVE-2026-115560 come indirizzi IP malevoli, domini, hash, payload o modelli di richieste di exploit confermati non sono attualmente disponibili.

Fino a quando non emergeranno maggiori dettagli tecnici, i difensori dovrebbero concentrarsi su indicatori basati su comportamenti e configurazioni, tra cui:

• Applicazioni PHP che cambiano session.serialize_handler durante l’esecuzione
• Il progresso del caricamento delle sessioni rimane abilitato su applicazioni con logica di sessione personalizzata
• Traffico POST multipart inaspettato verso applicazioni che gestiscono sessioni PHP
• Processi PHP-FPM, php-cgi, Apache o altri processi che servono PHP generando shell o interpreti script
• Connessioni di rete in uscita inaspettate da lavoratori PHP
• File creati di recente all’interno delle radici web o delle directory applicative scrivibili
• Modifiche insolite ai file di sessione o allo storage delle sessioni
• Web shell, job programmati o persistenze non autorizzate create da account di servizio PHP

Gli sviluppatori di applicazioni dovrebbero anche rivedere la logica di gestione delle sessioni personalizzate. Estensioni del framework, applicazioni legacy, piattaforme interne o sistemi di autenticazione personalizzati sono più propensi delle distribuzioni PHP dirette a modificare dinamicamente le impostazioni di serializzazione.

La divulgazione arriva durante un periodo già attivo di attività di sfruttamento PHP. Le vulnerabilità originali PHP2Shell sono state corrette il 21 ottobre e numerose aziende di sicurezza hanno successivamente osservato esplorazioni e tentativi di exploit diffusi. Tuttavia, PHP e i ricercatori di sicurezza non hanno collegato quelle campagne a CVE-2026-115560.

Mitigazione di CVE-2026-115560

PHP attualmente raccomanda una misura difensiva diretta:

session.upload_progress.enabled=0

Gli amministratori dovrebbero applicare l’impostazione tramite php.ini, configurazione del pool PHP-FPM, configurazione Apache o un altro meccanismo a livello di server che prenda effetto prima dell’elaborazione delle richieste.

Le organizzazioni che hanno disabilitato la funzione durante la mitigazione di CVE-2026-109619 e l’hanno lasciata disabilitata non necessitano di un cambiamento di configurazione aggiuntivo per questa vulnerabilità.

Dopo aver cambiato l’impostazione, riavviare i lavoratori PHP e i servizi web rilevanti per garantire che i processi esistenti carichino la configurazione aggiornata. A seconda dell’ambiente, ciò può includere il riavvio dei pool PHP-FPM, i lavoratori Apache, i container o altri processi runtime dell’applicazione PHP.

Gli amministratori possono verificare l’impostazione effettiva attraverso l’ispezione della configurazione PHP piuttosto che assumere che un valore php.ini centrale si applichi ovunque. Le distribuzioni PHP spesso combinano impostazioni da:

• php.ini globale
• file conf.d
• Configurazione del pool PHP-FPM
• Direttive di Apache
• Configurazione specifica del container
• .user.ini a livello di applicazione
• Chiamate runtime a ini_set()

L’assessment di esposizione più importante è specifico all’applicazione. Cercare nel codice sorgente dell’applicazione la modifica runtime del serializer delle sessioni, in particolare schemi che coinvolgono:

ini_set(‘session.serialize_handler’, ‘php’)

Le applicazioni che non cambiano mai il serializer da php_binary o php_serialize a php prima di session_start() non corrispondono allo scenario vulnerabile divulgato da PHP.

Le organizzazioni dovrebbero comunque mantenere gli aggiornamenti di sicurezza PHP2Shell del 21 ottobre. La disabilitazione del progresso del caricamento affronta il percorso recentemente identificato ma non sostituisce le correzioni di emergenza per CVE-2026-109618 e CVE-2026-109619.

Le installazioni supportate dovrebbero quindi rimanere almeno su:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Queste versioni risolvono i problemi PHP2Shell precedenti ma non la vulnerabilità di recente divulgazione.

I team di sicurezza dovrebbero anche inventariare le installazioni PHP non supportate. Le versioni PHP 8.1 e precedenti non ricevono più aggiornamenti di sicurezza ordinari a monte, il che significa che le organizzazioni che operano in ambienti legacy potrebbero avere difficoltà a determinare l’esposizione completa una volta pubblicato l’avviso CVE finale.

Se disabilitare il progresso del caricamento delle sessioni è operativamente impossibile, le organizzazioni dovrebbero prima determinare se le loro applicazioni modificano effettivamente dinamicamente il gestore di serializzazione. PHP afferma esplicitamente che le applicazioni che non eseguono mai questo cambiamento runtime possono lasciare abilitato il progresso del caricamento delle sessioni.

Come ulteriori salvaguardie, i difensori possono:

• Limitare l’accesso esterno alle applicazioni PHP sensibili.
• Applicare regole di proxy inverso restrittive attorno ai punti di fine caricamento file non necessari.
• Monitorare le richieste multipart associate alle sessioni PHP.
• Allertare sui processi figli anomali dei lavoratori PHP.
• Applicare il privilegio minimo agli account PHP-FPM e ai server web.
• Prevenire che i servizi PHP scrivano in directory eseguibili ove possibile.
• Limitare la connettività in uscita dai carichi di lavoro delle applicazioni web.
• Monitorare le radici web e le directory temporanee per la creazione di file non autorizzata.

AWS ha anche notato che le sue regole WAF per applicazioni PHP possono bloccare le richieste POST che combinano gli identificatori di sessione PHP con il campo PHP_SESSION_UPLOAD_PROGRESS, fornendo un altro strato di difesa per gli ambienti che non possono immediatamente effettuare cambiamenti nella configurazione. Questo tipo di filtraggio dovrebbe comunque essere considerato una difesa in profondità piuttosto che una sostituzione per il cambio di configurazione raccomandato da PHP.

Una volta che PHP rilascia l’aggiornamento regolare di correzione contenente la correzione permanente, le organizzazioni dovrebbero dispiegarlo prontamente anche se la mitigazione temporanea è già abilitata.

Dopo la patch, gli amministratori possono decidere se il progresso del caricamento delle sessioni deve essere riabilitato in base alle esigenze dell’applicazione.

Se si sospetta una sfruttamento, isolare il server dell’applicazione colpita e preservare la telemetria web, PHP, proxy inverso, endpoint e di rete. Rivedere le directory scrivibili per web shell o file creati di recente, ispezionare i processi figli PHP e identificare credenziali o segreti accessibili al servizio compromesso.

Poiché un’esecuzione di codice riuscita potrebbe potenzialmente portare a esecuzione con i privilegi del lavoratore PHP, i responder dovrebbero ruotare le credenziali dell’applicazione rilevanti, segreti dei database, token API, chiavi del cloud e altre informazioni sensibili se il compromesso non può essere escluso.

Dichiarazione di non responsabilità: Il contenuto di rilevamento potrebbe non essere disponibile per ogni CVE. Controllare la Piattaforma SOC Prime per la copertura attuale. Se i rilevamenti pertinenti non sono ancora disponibili, controllare nuovamente poiché nuove informazioni sulla minaccia e contenuti di rilevamento vengono continuamente aggiunti.