In breve: per la sicurezza del php.ini contano soprattutto quattro ambiti: nessun messaggio di errore verso l'esterno, cookie di sessione sicuri, upload limitati e valori bloccati che le applicazioni non possono sovrascrivere. Dopo PHP2Shell si aggiungono le misure provvisorie di php.net, soprattutto session.upload_progress.enabled=0. Una configurazione sicura non sostituisce però mai l'aggiornamento.
Perché dopo PHP2Shell il php.ini è di nuovo sotto osservazione
Il php.ini è il file di configurazione centrale di PHP. Su molti server è stato impostato una volta e poi quasi mai toccato. Con PHP2Shell le cose sono cambiate: per le due vulnerabilità CVE-2026-109618 e CVE-2026-109619 php.net indica misure provvisorie che agiscono proprio qui.
Le vulnerabilità stesse si trovano nell'interprete PHP. Sono corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, pubblicate il 21/10/2026. Una buona configurazione aiuta comunque in due modi: può rendere più difficile lo sfruttamento e limita il danno se qualcosa dovesse passare.
Inoltre molti gestori non sanno con precisione quali impostazioni valgano sul loro server. È il primo passo.
Quale php.ini vale sul Suo server?
A seconda della modalità di esecuzione, PHP può leggere file di configurazione diversi. La riga di comando, PHP-FPM e Apache con mod_php hanno, ad esempio su Debian e Ubuntu, ciascuno le proprie cartelle sotto /etc/php/<version>/. Chi modifica solo il file della CLI non cambia nulla per il sito web.
# File di configurazione della riga di comando
php --ini
# Configurazione di PHP-FPM (adattare il numero di versione)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Verificare singoli valori di PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Inoltre i valori possono trovarsi nel pool FPM, nella configurazione di Apache, in .htaccess (solo mod_php) o in .user.ini (FPM e CGI). Quale versione giri effettivamente sul server e se contenga un backport è spiegato nell'articolo Verificare correttamente la versione di PHP e lo stato delle patch.
Impostazioni di base per una maggiore sicurezza del php.ini
I valori seguenti sono sensati per la maggior parte dei server di produzione. Prima dell'uso verifichi in un ambiente di test che la Sua applicazione funzioni con tutti i valori.
; Nessuna indicazione di versione nell'header HTTP
expose_php = Off
; Registrare gli errori nel log, ma non mostrarli mai nel browser
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Non includere file da indirizzi remoti
allow_url_include = Off
; lasciare attivo allow_url_fopen solo se l'applicazione ne ha bisogno
allow_url_fopen = Off
; Sessioni: rigorose, solo tramite HTTPS, non leggibili con JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Limitare tempo di esecuzione e input
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
Alcune applicazioni hanno bisogno di allow_url_fopen per aggiornamenti o interfacce. Lo disattivi solo dopo aver verificato. Le funzioni che eseguono comandi di sistema si possono bloccare in aggiunta; come riuscirci senza effetti collaterali lo spiega la guida Usare correttamente disable_functions.
Misure provvisorie di php.net contro PHP2Shell
Se non può applicare subito la patch, php.net indica diverse impostazioni che riducono il rischio. Non sono espressamente una protezione completa, ma un ponte fino all'aggiornamento.
; Disattivare il session upload progress (anche per CVE-2026-115560)
session.upload_progress.enabled = 0
; Limitare la dimensione delle richieste: 8M senza upload, 32M con upload
post_max_size = 8M
upload_max_filesize = 6M
; Solo PHP 8.5: nessun backtrace in caso di errori gravi
fatal_error_backtraces = 0
Inoltre php.net raccomanda di impostare memory_limit=-1 in modo che le applicazioni non possano sovrascrivere il valore, e di fissare il limite di memoria tramite container o cgroup, non tramite RLIMIT_AS o RLIMIT_DATA. Questa misura va nel pool FPM o nella configurazione del server e dovrebbe essere combinata con un limite cgroup funzionante. La panoramica completa si trova in Misure immediate se non può ancora applicare la patch.
session.upload_progress.enabled=0 funziona solo da php.ini, pool FPM o configurazione del server. Se impostata tramite ini_set() o .user.ini, la misura non ha effetto. Poi riavviare tutti i worker.
Bloccare i valori contro la sovrascrittura
Molte applicazioni impostano valori propri, ad esempio per memoria o upload. Con php_admin_value e php_admin_flag fissa le impostazioni in modo che né ini_set() né .user.ini possano modificarle. Nel pool FPM appare così:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (estratto)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Con Apache e mod_php vale la stessa logica con php_admin_value e php_admin_flag nella configurazione del VirtualHost. Poi ricaricare il servizio e ricontrollare il valore attivo:
sudo systemctl reload php8.3-fpm
# Ora di avvio dei processi: è successiva alla modifica?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Un reload riavvia i worker di PHP-FPM. Dopo un aggiornamento di PHP, invece, è necessario un riavvio completo di tutti i processi PHP, in modo che nessun vecchio processo continui a girare in memoria. Con più siti su un server conviene inoltre un pool separato per ogni sito, maggiori dettagli nella guida open_basedir e isolamento per sito.
Errori frequenti e una breve lista di controllo
La maggior parte dei problemi con il php.ini non nasce da valori sbagliati, ma da valori nel posto sbagliato. Tipico è il file della CLI modificato mentre il sito gira tramite PHP-FPM. Altrettanto spesso dopo una modifica manca il riavvio, oppure un pannello di hosting sovrascrive l'impostazione al successivo salvataggio.
Un secondo classico sono i messaggi di errore visibili sul sito live. Rivelano percorsi, nomi di database o versioni e facilitano l'orientamento degli aggressori. Proprio dopo un trasloco o una nuova installazione display_errors risulta spesso di nuovo su On.
Questi punti vanno controllati dopo ogni modifica e dopo ogni aggiornamento di PHP:
- Quale file di configurazione legge la modalità di esecuzione web e contiene i Suoi valori?
display_errorseexpose_phpsono disattivati, il log degli errori è scrivibile?session.upload_progress.enabledè su0, impostato tramite php.ini o pool?- Le dimensioni di upload e richieste sono limitate in modo adatto all'applicazione?
- Tutti i processi PHP hanno un'ora di avvio successiva all'ultima modifica?
Annoti il risultato con la data. Così in seguito si potrà dimostrare quando valeva quale impostazione.
Come aiuta concretamente PHP SOS?
- Accertiamo quale configurazione sia effettivamente attiva in quale modalità di esecuzione.
- Applichiamo una configurazione di base concordata e le misure provvisorie contro PHP2Shell, testate con la Sua applicazione.
- Blocchiamo i valori rilevanti per la sicurezza contro la sovrascrittura e riavviamo tutti i worker in modo controllato.
- Documentiamo impostazioni e risultato dei controlli, in modo che le modifiche successive restino tracciabili.
Come si presenta una messa in sicurezza duratura è descritto nel servizio Hardening del server per server web PHP.
Domande frequenti
Quale php.ini usa in realtà il mio server web?
Spesso non è lo stesso della riga di comando. PHP-FPM, Apache con mod_php e CLI hanno di solito cartelle di configurazione proprie. Verifichi quindi il file attivo tramite la rispettiva modalità di esecuzione, ad esempio con php-fpm -i o con un file di prova depositato per breve tempo.
Un php.ini sicuro sostituisce l'aggiornamento di PHP?
No. Le impostazioni riducono la superficie di attacco e rendono più difficile lo sfruttamento, ma non chiudono una vulnerabilità nell'interprete PHP. Anche le misure provvisorie di php.net contro PHP2Shell non sono espressamente una protezione completa.
Qual è la differenza tra php_value e php_admin_value?
I valori impostati con php_value possono essere modificati di nuovo dall'applicazione durante l'esecuzione. I valori impostati con php_admin_value nel pool FPM o nella configurazione di Apache sono invece bloccati per l'applicazione, anche per ini_set() e .user.ini.
Devo riavviare dopo una modifica al php.ini?
Sì. PHP-FPM e Apache con mod_php leggono la configurazione solo all'avvio. I nuovi valori valgono solo dopo un riavvio o un reload di tutti i servizi interessati.