CVE-2026-115560: la RCE PHP che la patch PHP2Shell non corregge — verifica in 2 minuti

Due giorni dopo le release d'emergenza per PHP2Shell, il progetto PHP ha pubblicato un secondo avviso. Il 23 ottobre 2026 ha diffuso un "avviso informativo" per la CVE-2026-115560, un percorso di esecuzione di codice remoto attraverso il session upload progress che le release del 21 ottobre (8.5.12, 8.4.27, 8.3.36, 8.2.35) non correggono. Il consiglio di PHP: impostare session.upload_progress.enabled=0 fino alla prossima release di bugfix ordinaria.

PHP definisce il vettore "improbabile": richiede una combinazione insolita di configurazione e codice applicativo. È una buona notizia, ma non un motivo per ignorarlo. La mitigazione è una riga che la maggior parte dei siti non noterà mai, e gli attacchi PHP2Shell visti dal 21 ottobre sfruttano già la stessa funzione di upload progress (per la CVE-2026-109619). Qui sotto: chi è esposto, come verificare un host in due minuti con uno script gratuito e come applicare la mitigazione su ogni piattaforma.

In sintesi

• Cosa: CVE-2026-115560, esecuzione di codice remoto tramite session upload progress. Annunciata da PHP il 23 ottobre 2026 come avviso informativo; l'avviso completo arriverà con la prossima release.
• Corretta in: nessuna release per ora. L'aggiornamento a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 resta obbligatorio per PHP2Shell, ma non chiude questo percorso.
• Esposti solo se valgono tutte e tre: la configurazione imposta session.serialize_handler a php_binary o php_serialize; l'applicazione lo riporta a php con ini_set() prima di session_start(); session.upload_progress.enabled è ancora attivo (lo è di default).
• Mitigazione: session.upload_progress.enabled=0. Se l'avete applicata dopo l'avviso del 21 ottobre per la CVE-2026-109619, lasciatela: non serve altro.
• Gravità, versioni colpite, sfruttamento: PHP non ha pubblicato un punteggio né l'elenco delle versioni. Al 24 ottobre non abbiamo trovato segnalazioni di sfruttamento della CVE-2026-115560; gli attacchi visti dal 21 ottobre riguardano le due CVE PHP2Shell.
• Verifica gratuita: php2shell-check.sh 0.2.0 controlla le tre condizioni sul vostro host. In sola lettura, gira sulla vostra macchina, nulla esce dalla vostra rete.

Cosa ha annunciato PHP

La notizia di PHP del 23 ottobre dice, nella sostanza:

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. [...] The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled.

In breve: per proteggersi da un vettore RCE improbabile, PHP suggerisce di disattivare l'upload progress fino alla prossima release. Il problema si presenta solo se la configurazione usa php_binary o php_serialize, l'applicazione passa a php con ini_set() prima di session_start() e l'upload progress è attivo. Chi non cambia mai l'handler a runtime può lasciare la funzione attiva.

PHP gestisce la correzione nel ciclo di release ordinario, non come emergenza, e pubblicherà l'avviso completo per la CVE-2026-115560 con quella release.

La stessa impostazione era già tra le mitigazioni temporanee dell'avviso del 21 ottobre GHSA-6wmf-4rv5-p3rp per la CVE-2026-109619. Lì PHP descrive il session upload progress come "consumatore" confermato di stato obsoleto: può raggiungere la gestione delle sessioni prima della loro inizializzazione ordinaria, è attivo di default e non richiede che l'applicazione chiami session_start(). La nuova CVE è un percorso diverso attraverso la stessa funzione, e sopravvive alla patch.

Chi è esposto

Le tre condizioni restringono molto il campo:

1. Il serialize handler è cambiato in configurazione. Il default è php. Siete in ambito solo se php.ini, un file conf.d, un pool FPM, un php_value di Apache, .htaccess o .user.ini impostano session.serialize_handler a php_binary o php_serialize.
2. L'applicazione lo riporta a php a runtime. Qualcosa chiama ini_set('session.serialize_handler', 'php') prima di session_start(). Può stare nel vostro codice o in una libreria sotto vendor/.
3. Il session upload progress è attivo. Lo è di default in tutti i rami supportati, quindi la maggior parte degli host soddisfa questa condizione, a meno che qualcuno non l'abbia già spento per PHP2Shell.

Se i vostri server non toccano mai session.serialize_handler, PHP dice che potete tenere la funzione. In pratica molti team la spegneranno comunque: è una riga, e poche applicazioni usano i dati di upload progress in $_SESSION (le barre di caricamento moderne di solito misurano l'avanzamento nel browser).

Verificare un host in due minuti

Il nostro script gratuito ora controlla le tre condizioni, insieme ai controlli PHP2Shell che già faceva:

curl -fsSLO https://zerohunt.ai/self-check/php2shell-check.sh
sha256sum php2shell-check.sh           # confrontate con https://zerohunt.ai/self-check/SHA256SUMS
less php2shell-check.sh                # leggetelo prima
sudo sh php2shell-check.sh --scan /var/www/miaapp   # le vostre web root; default: /var/www /srv/www /usr/share/nginx

Nella sezione CVE-2026-115560 riporta, per ogni php.ini web (FPM, Apache, CGI, LiteSpeed, cPanel, Plesk, Remi, Docker) e ogni pool FPM, i valori effettivi di session.upload_progress.enabled e session.serialize_handler, poi elenca i file PHP, .htaccess o .user.ini sotto le web root che impostano il serialize handler. Il verdetto:

• [ok ] l'upload progress è spento ovunque sia impostato: la mitigazione è attiva;
• [ok ] l'upload progress è attivo ma nulla cambia l'handler a runtime: le condizioni non sono soddisfatte;
• [CHECK] del codice imposta il serialize handler: leggete quei file;
• [FIX ] la configurazione usa php_binary/php_serialize e il codice imposta l'handler: spegnete subito l'upload progress.

Lo script legge solo file e versioni. Non modifica nulla, non apre connessioni di rete e non invia nulla a nessuno. Sorgente e test: github.com/ZeroHunt-org/self-check.

Preferite verificare a mano? Bastano due comandi:

grep -rnE 'session\.(serialize_handler|upload_progress\.enabled)' /etc/php* /usr/local/etc/php* 2>/dev/null
grep -rn 'serialize_handler' --include='*.php' --include='.htaccess' --include='.user.ini' /var/www

Ricordate che la CLI legge un php.ini diverso da quello del web server: php -i da riga di comando non vi dice cosa usano PHP-FPM o mod_php.

Remediation

Impostate session.upload_progress.enabled a off dove lo legge il PHP web, poi riavviate PHP perché ogni worker lo recepisca.

• php.ini o un file conf.d (Debian/Ubuntu: /etc/php/<versione>/fpm/conf.d/ e /etc/php/<versione>/apache2/conf.d/; famiglia RHEL: /etc/php.d/):

  ; mitigazione CVE-2026-115560, fino alla prossima release di bugfix PHP
  session.upload_progress.enabled = 0
  

• Pool PHP-FPM, così le applicazioni non possono riattivarlo:

  php_admin_flag[session.upload_progress.enabled] = off
  

• Apache con mod_php, nella configurazione del server o del vhost:

  php_admin_flag session.upload_progress.enabled off
  

• Immagini Docker ufficiali php: aggiungete la riga in un file in /usr/local/etc/php/conf.d/, ricostruite e ridistribuite l'immagine.
• Hosting condiviso: alcuni provider hanno già disattivato la funzione per tutti i clienti; controllate l'avviso del vostro provider.

Poi riavviate: systemctl restart php8.3-fpm (la vostra versione), systemctl reload apache2 o httpd. Verificate con php-fpm8.3 -i | grep upload_progress o rilanciando lo script di verifica.

Tenete l'impostazione finché la release PHP che corregge la CVE-2026-115560 non è uscita e installata. E non consideratela una correzione per PHP2Shell: la CVE-2026-109618 e la CVE-2026-109619 richiedono comunque l'aggiornamento a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, come spiegato nella nostra guida alla remediation di PHP2Shell.

Cosa non si sa ancora

• Il punteggio di gravità e le versioni esatte colpite: PHP li pubblicherà con l'avviso completo.
• La data della correzione, oltre a "la prossima release di bugfix ordinaria".
• Se qualche framework o CMS diffuso cambia il serialize handler a runtime. Non abbiamo trovato segnalazioni pubbliche che ne nominino uno.

Un host non è tutta l'infrastruttura

Uno script vi parla dell'host su cui lo lanciate, oggi. La domanda più difficile in una settimana come questa è dove gira PHP che nessuno ricorda: un pannello di amministrazione dimenticato, un'appliance di un fornitore, un'immagine container costruita l'anno scorso. Zero Hunt è un AI red team autonomo su appliance on-premise, con modelli privati e un'approvazione umana per ogni azione rilevante. Mappa i servizi esposti nella vostra rete, verifica quali sono raggiungibili da un percorso d'attacco reale e ritesta dopo la patch per dimostrare che la correzione regge. Nulla esce dalla vostra rete. Il nostro team può mostrarvelo, e gli script di autoverifica gratuiti restano gratuiti.