In breve: un aggiornamento PHP su cPanel dopo PHP2Shell comprende tre passaggi: portare tutti i pacchetti ea-php ed eventualmente alt-php a uno stato corretto, riavviare per intero PHP-FPM e Apache e documentare lo stato dei pacchetti. I clienti sul server non possono impostare da soli i principali valori transitori: deve farlo l'amministratore WHM.
Situazione di partenza sui server cPanel
PHP2Shell comprende le vulnerabilità CVE-2026-109618 e CVE-2026-109619 in PHP stesso. Entrambe consentono l'esecuzione di codice dannoso senza autenticazione e sono valutate CVSS v4.0 9.2. Sono interessati PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il 21/10/2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
cPanel non fornisce PHP come pacchetto unico, ma tramite EasyApache 4, con un set di pacchetti per ogni versione, ad esempio ea-php83 o ea-php84. In alcuni server si aggiungono i pacchetti del sistema operativo e, su CloudLinux, le versioni alt-php. Ogni fonte ha un proprio stato. Un quadro completo si ottiene solo verificando tutte e tre.
Aggiornamento PHP su cPanel: verificare inventario e assegnazione
Cominci con un inventario. I comandi seguenti leggono soltanto e non modificano nulla. Percorsi e nomi dei pacchetti sono esempi e possono variare a seconda dell'installazione.
# Versioni PHP installate secondo l'API di WHM
whmapi1 php_get_installed_versions
# Versione di ogni installazione ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Stato dei pacchetti (sistemi basati su RPM, esempio)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
In MultiPHP Manager vede quale dominio usa quale versione e se PHP-FPM è attivato. Prenda nota delle versioni installate ma non assegnate ad alcun dominio. Vanno aggiornate o rimosse anche queste.
Inquadrare correttamente i backport
Come per altri fornitori, il numero di versione mostrato non è l'unico criterio. Se una correzione viene distribuita come backport, il numero può restare invariato. Controlli quindi anche il changelog del pacchetto e le indicazioni del fornitore.
# Cercare i numeri CVE nel changelog di un pacchetto (esempio)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Se non compare alcuna voce, non significa automaticamente che la correzione manchi. Significa però che serve una conferma scritta prima di classificare il server come aggiornato. Come leggere correttamente le versioni è spiegato alla pagina Verificare versione e stato della patch di PHP.
Aggiornamento, riavvio e controllo
L'aggiornamento si installa in WHM tramite l'aggiornamento di sistema oppure con la gestione dei pacchetti. Poi riavvii tutti i processi PHP. I nuovi file da soli non bastano finché in memoria girano vecchi processi.
# Riavviare i servizi PHP-FPM di tutte le versioni (script cPanel)
/scripts/restartsrv_apache_php_fpm
# Riavviare Apache per intero
/scripts/restartsrv_httpd
# Controllare l'orario di avvio dei processi PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Ogni processo PHP dovrebbe avere un orario di avvio successivo all'aggiornamento. Se non è così, lo termini in modo mirato tramite il servizio corrispondente. Con più server vale la pena tenere un breve verbale per ogni macchina, da usare in seguito come prova.
Un aggiornamento del CMS tramite strumenti cPanel come WP Toolkit non chiude la vulnerabilità di PHP. È sensato, ma non sostituisce né l'aggiornamento di PHP né il riavvio.
Impostare i valori transitori a livello centrale
Se una versione non è ancora corretta, php.net raccomanda misure transitorie che non offrono una protezione completa. Su cPanel le imposti in MultiPHP INI Editor in modalità amministratore oppure direttamente nel php.ini della rispettiva versione ea-php. I valori nei .user.ini degli account clienti non bastano per session.upload_progress.enabled.
; php.ini a livello di server della versione interessata (esempio)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Senza funzione di upload, php.net indica post_max_size = 8M. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. Poi riavvii di nuovo tutti i worker. Un limite di memoria si imposta tramite cgroup, ad esempio con i limiti di CloudLinux, non tramite RLIMIT_AS o RLIMIT_DATA. Altri dettagli alla pagina Misure immediate senza patch.
Responsabilità tra gestore del server e titolari degli account
Su un server cPanel con molti account, la responsabilità per PHP, i servizi e la configurazione a livello di server spetta all'amministratore WHM. I titolari dei singoli account sono responsabili delle proprie applicazioni, dei plugin e delle credenziali. Informi i titolari degli account su quando e come è stata applicata la patch e raccomandi loro di controllare le proprie applicazioni alla ricerca di anomalie. Come appare la situazione dal punto di vista del cliente è descritto alla pagina Shared hosting.
Conservi i log a partire dal 20/10/2026. Una patch non rimuove il malware introdotto in precedenza.
Per la prova basta un semplice verbale per ogni server: data e ora dell'aggiornamento, elenco dei pacchetti ea-php e alt-php con la versione prima e dopo, l'elenco dei processi con gli orari di avvio dopo il riavvio ed eventualmente la conferma del fornitore dei pacchetti sui backport. Conservi il verbale al di fuori del server. In seguito servirà da prova nei confronti di clienti, assicuratori o verificatori e facilita il prossimo aggiornamento d'emergenza, perché i passaggi sono già descritti. Se gestisce più server cPanel, vale la pena riunire i comandi di lettura di questa pagina in un piccolo script che giri in modo identico su tutte le macchine e raccolga i risultati. Così riconosce a colpo d'occhio le differenze tra server, ad esempio una versione di PHP dimenticata.
Come aiuta concretamente PHP SOS?
- Inventariamo i pacchetti ea-php, alt-php e di sistema e assegniamo tutti gli account alla rispettiva versione di PHP.
- Tramite il nostro servizio di patch PHP aggiorniamo, riavviamo tutti i servizi e documentiamo lo stato con elenchi dei pacchetti e orari dei processi.
- Dove necessario, impostiamo i valori transitori a livello di server e in modo non sovrascrivibile.
- Verifichiamo negli account le tipiche tracce di compromissione e, in caso di riscontro, avviamo la rimozione del malware.
- In seguito riduciamo il numero di versioni di PHP e rafforziamo la configurazione.
Domande frequenti
Dove vedo in WHM quale dominio usa quale versione di PHP?
In MultiPHP Manager di WHM vede per ogni dominio la versione assegnata e se PHP-FPM è attivo. Per un elenco completo conviene aggiungere la query da riga di comando. Annoti anche le versioni che non sono assegnate ad alcun dominio.
Un cliente cPanel può impostare da solo i valori transitori in .user.ini?
Per session.upload_progress.enabled php.net indica espressamente che .user.ini e ini_set() non bastano. Il valore va nel php.ini, nel pool FPM o nella configurazione del server. Può farlo solo l'amministratore del server.
Basta un riavvio graceful di Apache?
Con PHP-FPM devono essere riavviati i servizi FPM stessi: un reload di Apache non li rinnova. Con gli handler PHP basati su Apache la via sicura è un riavvio completo. Poi verifichi l'orario di avvio di tutti i processi PHP.
E CloudLinux e alt-php?
Sui server CloudLinux i siti web a volte girano con pacchetti alt-php propri invece di ea-php. Questi hanno uno stato dei pacchetti a sé e vanno verificati e aggiornati separatamente.