In breve: dopo l'aggiornamento di PHP deve riavviare PHP-FPM e tutti gli altri servizi che caricano PHP. I nuovi file sul disco non bastano finché vecchi processi PHP girano in memoria. Solo dopo il riavvio il server lavora con il codice corretto di PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o con il backport del Suo fornitore.
Perché deve riavviare PHP-FPM
Un aggiornamento di pacchetto sostituisce i file sul disco. I processi già in esecuzione, però, hanno già caricato in memoria il vecchio codice del programma e continuano a lavorare con quello. PHP-FPM, Apache con mod_php o LiteSpeed tengono in vita i loro worker spesso per giorni.
Per PHP2Shell è particolarmente importante. La vulnerabilità CVE-2026-109619 dipende proprio da uno stato che resta tra le richieste nello stesso worker. Un worker con il vecchio codice resta vulnerabile, qualunque versione si trovi sul disco. Secondo php.net, tutti i worker e i processi vanno quindi riavviati.
Alcuni gestori di pacchetti riavviano i servizi automaticamente durante l'aggiornamento, altri no. Non ci faccia affidamento, ma verifichi il risultato.
Un quadro tipico della quotidianità: la gestione dei pacchetti segnala «PHP aggiornato», il monitoraggio non mostra errori, il sito web funziona. Eppure i vecchi worker continuano a servire ogni richiesta, perché nessuno ha riavviato il servizio. Dall'esterno questo stato non si riconosce. Per questo la verifica degli orari di avvio dei processi fa parte di ogni aggiornamento.
Quali servizi caricano PHP?
| Modalità di esecuzione | Che cosa riavviare | Comando tipico (nomi variabili a seconda della distribuzione) |
|---|---|---|
| PHP-FPM | ogni servizio FPM, per ogni versione installata | systemctl restart php8.3-fpm oppure systemctl restart php-fpm |
| Apache con mod_php | Apache | systemctl restart apache2 oppure systemctl restart httpd |
| php-cgi | il web server chiamante o il wrapper FastCGI | a seconda della configurazione |
| LiteSpeed | LiteSpeed e i processi lsphp | tramite la gestione di LiteSpeed o il suo servizio |
| FrankenPHP | il servizio FrankenPHP o il container | systemctl restart frankenphp oppure ricreare il container |
| Docker, Kubernetes | ricreare i container da una nuova immagine | vedi Applicare la patch a PHP nei container Docker |
Con mod_php vale: l'aggiornamento riguarda Apache stesso, perché PHP è presente in ogni processo Apache. Perché questa modalità sia particolarmente delicata è spiegato alla pagina Perché mod_php comporta il rischio più alto. Per LiteSpeed trova i dettagli alla pagina LiteSpeed e LSAPI.
Riavviare PHP-FPM: i comandi
Per prima cosa trovi tutti i servizi PHP sul server. Plesk, cPanel e altre interfacce portano con sé servizi PHP propri con nomi propri; l'elenco li mostra.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Poi riavviare ogni servizio PHP trovato, non solo il primo:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # se è installato un secondo ramo
sudo systemctl restart apache2 # con mod_php; famiglia RHEL: httpd
Raccomandiamo restart anziché reload. Con il reload il processo principale resta; è pensato per le modifiche di configurazione. Dopo un aggiornamento di sicurezza vuole essere certo che ogni processo sia nuovo.
Se ha impostato anche misure provvisorie come session.upload_progress.enabled=0 o limiti di memoria fissi, anch'esse hanno effetto solo dopo il riavvio. Un riavvio sbriga entrambe le cose in un solo passaggio.
Verificare che nessun vecchio worker giri ancora
Confronti l'ora di avvio dei processi con il momento dell'aggiornamento. Tutti i comandi sono di sola lettura.
ps -o pid,lstart,cmd -C php-fpm8.3 # su RHEL: -C php-fpm
systemctl status php8.3-fpm # riga «Active: … since …»
needrestart -r l # Debian/Ubuntu, se installato
Se un processo è più vecchio dell'aggiornamento, non è stato interessato. Cause frequenti sono un secondo ramo PHP dimenticato, un servizio di pool proprio proveniente da un pannello di hosting o un container che è stato solo riavviato invece di essere ricreato dalla nuova immagine. Quale versione giri lo mostra la pagina Verificare correttamente versione e stato delle patch di PHP.
Documentare il riavvio
Annoti per ogni server il momento dell'aggiornamento e del riavvio. Questo istante separa il periodo in cui il server era vulnerabile da quello successivo. Per una successiva verifica delle tracce, per gli assicuratori e per un'eventuale notifica ai sensi del GDPR è il riferimento più importante. Conservi inoltre i log del server a partire dal 20 ottobre, come consiglia la stampa specializzata.
Sui server con molti siti web vale la pena una breve tabella: server, servizio, versione di PHP, versione del pacchetto, momento del riavvio e persona che ha riavviato. In questo modo le lacune di copertura emergono in fretta, ad esempio un pool trascurato o un sistema di test che nessuno aveva in elenco.
Come aiuta concretamente PHP SOS?
Nell'ambito del servizio di patch PHP ci occupiamo di aggiornamento e riavvio come processo unico:
- Individuare i servizi: troviamo tutti i processi che caricano PHP, anche quelli provenienti da pannelli di hosting e container.
- Riavviare in modo controllato, previo accordo con Lei a un momento adatto e con attenzione a ordini o moduli in corso.
- Ricontrollare che nessun processo sia più vecchio dell'aggiornamento e che il sito web risponda normalmente.
- Verbalizzare: versioni, stati dei pacchetti e orari di riavvio per ogni server.
Domande frequenti
Basta systemctl reload invece di restart?
Per PHP2Shell raccomandiamo restart. Un reload di solito riavvia i worker, ma il processo principale può continuare a girare. Con restart si ha la certezza che non resti alcun processo con il vecchio codice. All'interruzione breve si contrappone una prova chiara.
Dopo l'aggiornamento di PHP devo riavviare l'intero server?
Di norma no. Basta riavviare tutti i servizi che caricano PHP: PHP-FPM, Apache con mod_php, LiteSpeed, FrankenPHP o i container interessati. Riavviare l'intero server è la variante semplice se non è sicuro di quali servizi usino PHP.
Il mio hoster riavvia PHP automaticamente dopo l'aggiornamento?
Dipende dal fornitore. Chieda in modo concreto se dopo la patch tutti i processi PHP siano stati riavviati e se lo faccia confermare per iscritto.