Situazione attuale: PHP2Shell. Due vulnerabilità critiche di PHP (CVSS 9,2) consentono codice dannoso senza autenticazione. Patch dal 21/10/2026.Che cosa fare ora →

Disattivare session.upload_progress: nel modo giusto e per sempre

Il rimedio contro CVE-2026-115560 e una delle misure transitorie per PHP2Shell si imposta in fretta. Perché regga, deve stare nel punto giusto, essere bloccata e venire ricontrollata dopo ogni aggiornamento.

Stato 6 min di letturaHardening e configurazione

In breve: imposti session.upload_progress.enabled=0 in php.ini, nel pool PHP-FPM o nella configurazione del server Apache, mai tramite ini_set() o .user.ini, e riavvii poi tutti i worker PHP. La misura diventa duratura solo quando il valore è bloccato contro la riattivazione, vale in ogni modalità di esercizio e in ogni versione di PHP installata e viene ricontrollato dopo gli aggiornamenti.

Una piccola impostazione con un duplice effetto

Raramente una singola impostazione di PHP ha ricevuto tanta attenzione. Quando il 21 ottobre 2026 php.net ha pubblicato le patch contro PHP2Shell, session.upload_progress.enabled=0 figurava nell'elenco delle misure transitorie. Due giorni dopo è seguito l'avviso su CVE-2026-115560, e il rimedio raccomandato era la stessa impostazione.

In quei giorni molti amministratori l'hanno impostata in fretta. Se agisca ovunque è un'altra questione. Le lacune tipiche si elencano presto: il valore è presente solo nella configurazione CLI, una seconda versione di PHP è stata dimenticata, oppure un pannello di hosting ha sovrascritto il file al salvataggio successivo. Questo articolo mostra come attuare la misura in modo che valga ancora tra tre mesi.

Importante in anticipo: la disattivazione non sostituisce l'aggiornamento di PHP. Secondo i rapporti specializzati, session.upload_progress.enabled=0 da solo non chiude entrambe le vulnerabilità di PHP2Shell. Che cosa riguardi esattamente CVE-2026-115560 lo spiega la pagina CVE-2026-115560: avviso su session upload progress.

Che cosa fa la funzione e a chi serve

Il session upload progress scrive continuamente nella sessione, durante un upload di file, lo stato di avanzamento, in modo che un'applicazione possa mostrare una barra di avanzamento. In PHP la funzione è attiva in modo predefinito. Il manuale PHP stesso fa notare che in questo modo nomi di file e di campi forniti dal mittente finiscono non verificati nell'archivio delle sessioni, e raccomanda di disattivare la funzione se l'applicazione non la usa.

Se la Sua applicazione la usi lo scopre con una ricerca puramente in lettura nel codice:

# Cerca gli usi della funzione di avanzamento nel codice dell'applicazione
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/

Se la ricerca non trova nulla, può disattivare la funzione senza conseguenze percettibili. Se ci sono riscontri, l'applicazione perde solo l'indicatore di avanzamento, non l'upload. I moduli moderni misurano comunque per lo più l'avanzamento nel browser.

Impostare session.upload_progress.enabled nel punto giusto

Secondo il manuale PHP l'impostazione ha la modalità INI_PERDIR. Significa: si può impostare in php.ini, nella configurazione del server, in .htaccess (solo mod_php) e in .user.ini (solo FPM e CGI), ma non in fase di esecuzione. php.net esclude espressamente .user.ini come luogo per la misura. La tabella seguente mostra i luoghi sensati per ogni modalità di esercizio.

Modalità di esercizio Luogo raccomandato Blocca la sovrascrittura? Riavviare poi
PHP-FPM file del pool con php_admin_flag sì ogni servizio FPM
PHP-FPM php.ini della SAPI FPM no, .user.ini potrebbe sovrascrivere ogni servizio FPM
Apache con mod_php VirtualHost o configurazione del server con php_admin_flag sì Apache completamente
php-cgi, LiteSpeed, FrankenPHP php.ini del rispettivo runtime verificare secondo la struttura tutti i processi del runtime
Immagine Docker file proprio in /usr/local/etc/php/conf.d/ durante la build sì, se non è consentito alcun override ricreare il container

Le due varianti robuste hanno questo aspetto:

; PHP-FPM, ad es. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
# Apache con mod_php, nel VirtualHost o a livello di server
<IfModule php_module>
    php_admin_flag session.upload_progress.enabled off
</IfModule>

In più vale la pena inserire la voce nel php.ini di ogni SAPI web come valore di base. Allora l'impostazione vale anche per i nuovi pool che qualcuno creerà in seguito. Perché php_admin_flag faccia la differenza lo descrive l'articolo php_admin_value: bloccare le impostazioni contro la sovrascrittura.

Verificare l'efficacia nel contesto web

La riga di comando legge spesso un php.ini diverso da quello del server web. Un php -i dimostra quindi poco. Anche php-fpm8.3 -i mostra solo i valori di php.ini, non le voci dei pool. Affidabile è solo una richiesta che passa davvero dal pool.

Proceda così:

  1. Riavviare tutti i servizi PHP, ad esempio systemctl restart php8.3-fpm o Apache con mod_php. Senza riavvio continua a valere il vecchio valore.
  2. Collocare nel webroot un breve file di prova con un nome casuale che emetta solo il valore attuale.
  3. Richiamare il file una volta tramite il dominio reale e annotare il risultato.
  4. Cancellare subito il file e ripetere il passo per ogni sito e ogni pool.
<?php
// File di prova: collocarlo solo per poco, poi cancellarlo subito
header('Content-Type: text/plain');
echo 'session.upload_progress.enabled = ', var_export(ini_get('session.upload_progress.enabled'), true), "\n";
echo 'PHP ', PHP_VERSION, ' / SAPI ', PHP_SAPI, "\n";

Ci si aspetta un valore vuoto o '0'. Se compare '1', la Sua impostazione non agisce in quel pool. Dopo un aggiornamento di PHP verifichi inoltre che tutti i worker siano stati riavviati, come descritto in Riavviare PHP-FPM e tutti i worker.

Importante

Non lasci mai in giro file di prova. Rivelano versioni e configurazione e sono un bersaglio gradito delle scansioni automatiche.

Perché l'impostazione resti nel tempo

La maggior parte delle ricadute non nasce da aggressori, ma dall'esercizio. Un nuovo pool viene copiato da un vecchio modello, un aggiornamento di pacchetto crea un nuovo php.ini oppure qualcuno cambia la versione di PHP nel pannello di hosting. Contro queste ricadute aiutano abitudini consolidate.

  • Coprire tutte le versioni: su molti server girano più versioni di PHP in parallelo. Ognuna ha cartelle di configurazione proprie e richiede la voce.
  • Adattare i modelli: modelli di pool, ruoli Ansible, Dockerfile e modelli del pannello contengono il valore, in modo che i nuovi siti lo ereditino automaticamente.
  • Usare le impostazioni del pannello: nei pannelli di hosting il valore va nelle direttive aggiuntive previste dal pannello, altrimenti la modifica successiva sovrascrive il lavoro manuale.
  • Verificare dopo gli aggiornamenti: la verifica della sezione precedente rientra nella checklist di ogni aggiornamento di PHP.
  • Documentare: annotare data, server, pool e risultato. Serve poi nei confronti di direzione, assicuratore o verificatori.

Chi non usa affatto .user.ini può disattivare del tutto la lettura di tali file con user_ini.filename = nel php.ini. Questo riguarda però tutte le impostazioni che le applicazioni vi collocano. Provi quindi prima questo passo, soprattutto con i CMS che scrivono propri file .user.ini.

Le altre misure transitorie di php.net, ad esempio i limiti per post_max_size e il limite di memoria tramite cgroup, sono raccolte in Misure immediate se non può ancora applicare la patch. Come PHP ordina in via di principio i propri livelli di configurazione lo spiega Il php.ini spiegato.

Come aiuta PHP SOS in concreto?

  • Rilevare lo stato: stabiliamo tutte le versioni di PHP, modalità di esercizio e pool sui Suoi server e leggiamo i valori effettivi nel contesto web.
  • Impostare in modo pulito: inseriamo l'impostazione bloccata nei pool e nella configurazione del server e riavviamo in modo controllato tutti i worker.
  • Testare la funzione: dopo il passaggio verifichiamo moduli di upload e gestione dei media.
  • Prevenire le ricadute: adattiamo modelli, deployment e impostazioni del pannello e documentiamo lo stato nell'ambito dell'hardening del server.

Domande frequenti

Perché session.upload_progress.enabled=0 non funziona tramite ini_set()?

Secondo il manuale PHP, l'impostazione appartiene alla modalità INI_PERDIR. Non si può quindi modificare affatto in fase di esecuzione con ini_set(). php.net indica come luoghi corretti php.ini, il pool FPM o la configurazione del server ed esclude espressamente .user.ini.

Gli upload di file funzionano ancora dopo la disattivazione?

Sì. Viene disattivata solo la segnalazione di avanzamento che PHP scrive nella sessione durante un upload. L'upload stesso prosegue. Sono interessate solo le applicazioni che costruiscono la propria barra di avanzamento proprio con questa funzione di PHP.

Un'applicazione può riattivare la funzione?

In linea di principio sì, tramite un file .htaccess con mod_php o un .user.ini con PHP-FPM, finché il valore non è bloccato. Con php_admin_flag nel pool o nella configurazione di Apache lo impedisce.

Devo reimpostare il valore dopo il prossimo aggiornamento di PHP?

No, non è necessario. La funzione non serve alla maggior parte delle applicazioni, e lo stesso manuale PHP consiglia di disattivarla in questi casi. Dopo ogni aggiornamento verifichi solo che il valore valga ancora.

Fonti

Contatto immediato

Ogni ora conta. Ci scriva adesso.

Descriva brevemente sistema, versione di PHP e quanto osservato. Ci faremo sentire, chiariremo la situazione e lavoreremo da remoto fino alla chiusura e alla documentazione dell'incidente.

Aiuto immediato