In breve: per gli amministratori senza background da sviluppatore bastano cinque nozioni di base per gestire PHP in sicurezza: PHP è composto da più programmi (riga di comando, PHP-FPM, modulo Apache), ciascuno con una propria versione; le impostazioni agiscono per livelli, dal php.ini all'applicazione; PHP-FPM distribuisce le richieste ai worker in pool; un aggiornamento ha effetto solo dopo il riavvio di tutti i processi; e i log sono l'indizio più importante quando qualcosa non va. Chi conosce questi punti può chiudere vulnerabilità come PHP2Shell in modo rapido e dimostrabile.
Di che cosa è fatto PHP su un server
PHP non è un singolo programma. Su un tipico server Linux si trovano più varianti, ciascuna collegata tramite un'interfaccia del server (SAPI):
| Variante | Nome tipico | A che cosa serve |
|---|---|---|
| Riga di comando (CLI) | php, php8.3 |
cronjob, Composer, script di manutenzione |
| PHP-FPM | php-fpm, php-fpm8.3 |
richieste web dietro Nginx o Apache |
| Modulo Apache | mod_php, libphp |
richieste web direttamente nel processo Apache |
| CGI | php-cgi |
strutture più vecchie |
Ogni variante può avere una versione diversa e un php.ini diverso. Su molti server girano inoltre più versioni di PHP in parallelo, ad esempio 8.2 e 8.4. In un aggiornamento ciascuna va considerata singolarmente. Come lavorano le interfacce lo spiega PHP-FPM spiegato.
Quale variante serva effettivamente i Suoi siti web lo scopre dai processi in esecuzione e dalla configurazione del server web:
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php # Apache carica un modulo PHP?
ls /run/php/ 2>/dev/null # socket FPM, spesso per versione e pool
La colonna con l'ora di avvio è importante in seguito per il riavvio: tutti i processi PHP devono essere stati avviati dopo il momento dell'aggiornamento. Se i processi girano con utenti diversi, ciò indica pool separati, il che è un bene. Se in Apache compare un modulo PHP benché tutti i siti web debbano girare tramite FPM, è un indizio di un residuo del passato che va rimosso. Per le interfacce di hosting come Plesk o cPanel vale lo stesso principio, solo che l'interfaccia mostra versioni e handler per ogni sito web; resta però determinante ciò che gira effettivamente come processo.
I comandi più importanti per gli amministratori
php -v # versione della riga di comando
php --ini # php.ini caricato e directory lette in aggiunta
php --ini=diff # da PHP 8.5: scostamenti dal valore predefinito
php -m # moduli compilati e caricati
php --ri session # impostazioni di un'estensione
php -l datei.php # controllo della sintassi senza esecuzione
php-fpm8.3 -v # versione del binario FPM (nome a seconda della distribuzione)
php-fpm8.3 -t # testare la configurazione FPM senza riavviare
systemctl status php8.3-fpm
Due avvertenze dal manuale: php -l trova errori di sintassi, ma non gli errori che si verificano solo in fase di esecuzione. E php -i richiama phpinfo(); l'output non appartiene a file pubblici nella directory web.
Come agiscono le impostazioni di PHP
Un'impostazione può essere definita in più punti. Chi possa modificare che cosa lo regola la modalità di modifica di ogni direttiva:
- php.ini e conf.d: configurazione di base per variante, letta all'avvio.
- Pool FPM:
php_valueephp_admin_valueper pool. I valori impostati conphp_admin_value, secondo il manuale, l'applicazione non può sovrascriverli conini_set(). - Livello di directory:
.user.inicon FPM o.htaccesscon mod_php, solo per direttive in modalitàINI_PERDIRoINI_ALL. - Applicazione:
ini_set()in fase di esecuzione, solo per direttive in modalitàINI_ALL.
Un esempio: memory_limit ha la modalità INI_ALL, quindi può essere modificato dall'applicazione. post_max_size ha INI_PERDIR e non si lascia modificare con ini_set(). Per questo php.net richiede, nelle misure transitorie PHP2Shell, di impostare i valori in modo che le applicazioni non possano sovrascriverli. I dettagli sui livelli li spiega Il php.ini spiegato.
I pool PHP-FPM in breve
Un pool è un gruppo di worker con utente, socket e impostazioni propri. Le direttive più importanti secondo il manuale:
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic ; static, dynamic oppure ondemand
pm.max_children = 20 ; al massimo 20 richieste contemporanee
pm.max_requests = 500 ; rinnovare il worker dopo 500 richieste
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
Un pool proprio per ogni sito web con utente proprio separa i siti web l'uno dall'altro. security.limit_extensions è per impostazione predefinita su .php .phar e impedisce a FPM di eseguire estensioni di file diverse da PHP. clear_env è attivato per impostazione predefinita e tiene le variabili d'ambiente lontane dal worker.
Log: dove devono guardare gli amministratori
PHP scrive gli errori nella destinazione stabilita con error_log, PHP-FPM inoltre nel proprio log e, per le richieste lente, nello slowlog con backtrace. A ciò si aggiungono i log degli accessi e degli errori del server web. Faccia attenzione che in produzione display_errors sia disattivato e log_errors attivato: gli errori appartengono al log, non alla pagina web. I log dovrebbero inoltre essere ruotati e conservati per un periodo stabilito, perché nel caso grave esistano ancora. Dopo PHP2Shell la stampa specializzata raccomanda di conservare i log del server dal 20/10/2026. Un forte segnale d'allarme è un processo PHP-FPM o del server web che avvia una shell; come riconoscerlo lo si trova in Segnale d'allarme: il server web avvia una shell.
Checklist per gli amministratori dopo PHP2Shell
- Elencare tutte le varianti e le versioni di PHP sul server, anche quelle non usate.
- Verificare lo stato dei pacchetti; per i backport della distribuzione cercare nel changelog CVE-2026-109618 e CVE-2026-109619.
- Aggiornare a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 ovvero al backport confermato.
- Riavviare PHP-FPM, Apache e LiteSpeed e controllare gli orari di avvio dei processi.
- Controprova con
php -r 'var_dump(ini_get("memory_hard_limit_percent"));';bool(false)significa, secondo il manuale, una versione interessata. - Mettere al sicuro i log e verificare eventuali anomalie.
Come dimostrare in modo affidabile versione e stato delle patch lo descrive Verificare correttamente la versione di PHP e lo stato delle patch.
Come aiuta concretamente PHP SOS?
Nel contratto di manutenzione della sicurezza ci occupiamo con il Suo team della manutenzione di base di PHP:
- Inventario: tutte le varianti di PHP, versioni, pool e posizioni di configurazione per ogni server.
- Configurazione: valori rilevanti per la sicurezza impostati con
php_admin_value, pool separati per ogni sito web. - Aggiornamenti: installazione, riavvio, controllo e documentazione a ogni rilascio di sicurezza.
- Trasferire il sapere: spieghiamo ai Suoi amministratori che cosa abbiamo modificato e perché.
Domande frequenti
Perché php -v mostra una versione diversa da quella del sito web?
Riga di comando, PHP-FPM e modulo Apache sono programmi separati con versione e php.ini propri. php -v mostra solo la riga di comando. Per il sito web conta la versione del binario che elabora effettivamente le richieste.
Quale php.ini vale sul mio server?
Lo mostra php --ini per la riga di comando. Per PHP-FPM di solito esiste un php.ini proprio e ulteriori file di pool. Da PHP 8.5 php --ini=diff mostra quali valori si discostano dal valore predefinito.
Qual è la differenza tra php_value e php_admin_value?
Entrambi impostano valori in un pool FPM. I valori impostati con php_admin_value, secondo il manuale, l'applicazione non può sovrascriverli con ini_set(). Per le impostazioni rilevanti per la sicurezza php_admin_value è quindi la scelta giusta.
Basta un aggiornamento senza riavvio?
No. I processi PHP in esecuzione mantengono in memoria il vecchio codice. Dopo un aggiornamento vanno riavviati PHP-FPM, Apache con mod_php o LiteSpeed, altrimenti continua a girare la versione vulnerabile.