Più versioni PHP su un server: aggiornare ciascuna singolarmente

In breve: se su un server girano più versioni di PHP, dopo PHP2Shell ciascuna va verificata, aggiornata e riavviata singolarmente. Le fonti tipiche sono il sistema operativo, pannelli di hosting come Plesk o cPanel, fonti di terzi come sury.org o Remi, CloudLinux, LiteSpeed e versioni compilate in proprio. Solo un elenco completo ricavato da pacchetti, file e processi in esecuzione mostra se davvero nessuna versione è stata trascurata.

La versione dimenticata

Un server che gira da qualche anno accumula versioni di PHP come una soffitta vecchi mobili. Il pannello ha portato tre rami, per un cliente è arrivata una versione più vecchia da una fonte di terzi, il sistema operativo ha la sua. Ognuna è stata installata a suo tempo per un buon motivo. Solo che oggi nessuno sa più quale sia ancora necessaria.

Dopo PHP2Shell è proprio questo il problema. Le correzioni sono uscite il 21 ottobre 2026 per PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Ogni installazione sul server le riceve però per la propria strada, dal proprio responsabile del pacchetto e nei propri tempi. Per PHP 8.1 e precedenti esistono solo backport minimi del sorgente. Chi aggiorna solo la versione principale lascia aperte le altre.

Da dove vengono le tante versioni

La panoramica seguente indica fonti tipiche e percorsi di esempio. I percorsi esatti variano per versione e distribuzione.

Particolarmente insidiosi sono i pacchetti sury.org, perché usano gli stessi percorsi della distribuzione. Se un php8.3 provenga da Debian o da sury.org lo mostra solo la fonte del pacchetto. Le particolarità sono descritte negli articoli Il repository sury.org e Il repository Remi. Come Plesk gestisce le sue versioni lo descrive la pagina Server Plesk: verificare e aggiornare le versioni di PHP.

Trovare tutte le installazioni di PHP

Un elenco affidabile nasce da tre punti di vista. I comandi sono di sola lettura e, a seconda del server, possono girare per un po'.

# 1. Pacchetti: ciò che conosce la gestione dei pacchetti
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. File: binari PHP eseguibili, anche fuori dalla gestione dei pacchetti
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Processi: ciò che gira davvero in questo momento, con l'ora di avvio
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Confronti i tre elenchi. Un file senza pacchetto indica una versione compilata in proprio o copiata a mano. Un processo senza file corrispondente può indicare un'installazione cancellata ma ancora in esecuzione. Con Apache verifichi inoltre se è caricato un modulo PHP, ad esempio con apache2ctl -M o httpd -M. I container e i pod Kubernetes compaiono in questi elenchi solo in parte e richiedono una verifica separata delle immagini.

Aggiornare ogni versione singolarmente

Quando ogni installazione ha una riga nel Suo elenco, per ciascuna segue la stessa procedura:

1. Chiarire la responsabilità: la patch viene dalla distribuzione, dal pannello, da una fonte di terzi o da Lei stesso?
2. Valutare lo stato: versione corretta ufficiale, backport confermato, non chiarito o aperto.
3. Aggiornare: per la via della rispettiva fonte, non per un'altra.
4. Riavviare: il servizio di quella versione, non solo il servizio principale. Con mod_php il server web. I dettagli sono in Riavviare PHP-FPM e tutti i worker.
5. Controllare: confrontare l'ora di avvio dei processi con il momento dell'aggiornamento.
6. Documentare: versione, stato del pacchetto, prova, ora del riavvio.

Per le versioni per le quali non esiste una patch valgono, fino alla migrazione, le misure transitorie di php.net. Le imposti separatamente per ogni versione, perché ogni installazione ha il proprio php.ini e i propri pool.

Quale versione usa la riga di comando, quale il container?

Due ambiti sfuggono particolarmente spesso alla ricerca. Il primo è la riga di comando. Su Debian e Ubuntu il sistema delle alternative decide quale binario si nasconda dietro il comando php. update-alternatives --display php mostra quali versioni sono registrate e quale vale al momento. I cron job che richiamano un percorso fisso come /usr/bin/php7.4 aggirano però questa impostazione. Per questo vale la pena guardare i crontab di tutti gli utenti e la configurazione dei pannelli che creano cron job propri.

Il secondo ambito sono i container. Un container Docker sul server porta con sé la propria versione di PHP, che non compare in nessun elenco di pacchetti dell'host. docker ps mostra i container in esecuzione; se contengano PHP e in quale versione lo rivela uno sguardo all'immagine o un php -v nel container. La patch lì non si fa sull'host, ma ricostruendo l'immagine e sostituendo il container.

Meno è più sicuro

Il miglior controllo è quello che non occorre fare. Ogni versione di PHP installata raddoppia il lavoro alla prossima vulnerabilità. Dopo PHP2Shell conviene quindi una regola chiara: ogni versione sul server ha bisogno di uno scopo e di un responsabile. Ciò che non li ha viene prima disattivato e, dopo un periodo di osservazione, rimosso. Altro nell'articolo Disattivare le vecchie versioni di PHP nel pannello di hosting.

Come aiuta concretamente PHP SOS?

• Creiamo per i Suoi server un elenco completo di tutte le installazioni di PHP da pacchetti, file, processi e container.
• Chiariamo per ogni versione origine, responsabilità e stato della patch.
• Nell'ambito del servizio di patch PHP aggiorniamo ogni versione, riavviamo ogni servizio e documentiamo lo stato.
• Insieme a Lei stabiliamo quali versioni restano e rimuoviamo le altre in modo controllato.

Domande frequenti

Fonti

• php.net: segnalazioni di sicurezza
• php.net: versioni supportate
• Red Hat Security Bulletin RHSB-2026-013