In breve: un aggiornamento PHP su Plesk è concluso solo quando ogni versione di PHP installata è a uno stato corretto, tutti i servizi PHP-FPM sono stati riavviati e può dimostrarlo con lo stato dei pacchetti e l'orario di avvio dei processi. Il numero di versione mostrato nel pannello non basta, perché i backport spesso lo lasciano invariato.
Di che cosa si tratta con PHP2Shell sui server Plesk
PHP2Shell indica due vulnerabilità critiche in PHP stesso (CVE-2026-109618 e CVE-2026-109619, entrambe CVSS v4.0 9.2). Consentono agli aggressori di eseguire codice sul server senza autenticazione. Sono interessati, tra gli altri, PHP-FPM e Apache con mod_php, cioè proprio le modalità di esecuzione che Plesk configura per i siti web.
Il 21/10/2026 il progetto PHP ha pubblicato le versioni corrette 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali. I server Plesk hanno una particolarità: qui spesso girano più versioni di PHP affiancate, in parte fornite da Plesk stesso, in parte dal sistema operativo. Ognuna richiede una verifica propria.
Un aggiornamento nel pannello sostituisce i file sul disco. Finché in memoria girano vecchi processi PHP, la vulnerabilità resta aperta. Senza il riavvio di tutti i worker, la patch non è efficace.
Aggiornamento PHP su Plesk: prima rilevare l'esistente
Prima di aggiornare qualsiasi cosa, si procuri un elenco di tutti gli handler PHP e dei domini che li usano. Può farlo dal pannello (Strumenti e impostazioni, Impostazioni PHP) o da riga di comando. I comandi seguenti non modificano nulla, leggono soltanto.
# Tutti gli handler PHP registrati con versione e percorso
plesk bin php_handler --list
# Versione di ogni PHP installato da Plesk (percorso a titolo di esempio)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Annoti per ogni handler: versione, modalità di esecuzione (FPM, FastCGI, modulo Apache) e numero di domini. Gli handler senza domini non sono un segnale di via libera. Possono essere assegnati in seguito o girare su sottodomini di test.
Verificare lo stato dei pacchetti, non l'indicazione a schermo
Plesk mostra il numero di versione che PHP stesso riporta. Se Plesk o la distribuzione forniscono la correzione come backport, può comparire ancora, ad esempio, 8.2.34 anche se la correzione è inclusa. Viceversa, un numero che sembra aggiornato può ingannare se un pacchetto non è stato ancora allineato. Contano lo stato dei pacchetti installati e la conferma scritta del fornitore.
# Debian/Ubuntu (nomi dei pacchetti a titolo di esempio)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (nomi dei pacchetti a titolo di esempio)
rpm -qa | grep -E 'plesk-php|^php' | sort
Confronti le versioni dei pacchetti con le indicazioni dei changelog di Plesk e con le note della Sua distribuzione. Se non è documentato in modo chiaro che CVE-2026-109618 e CVE-2026-109619 sono corrette, lo chieda al fornitore. Un modello per farlo si trova alla pagina Chiedere all'hoster lo stato della patch.
Installare l'aggiornamento e riavviare tutti i worker
L'aggiornamento vero e proprio passa dall'installer di Plesk o dalla gestione dei pacchetti del sistema. Poi segue il passaggio che manca più spesso: il riavvio. Con Plesk ogni versione di PHP ha un proprio servizio FPM. Li riavvii tutti, non solo quello del dominio principale.
# Elencare tutti i servizi PHP-FPM (nomi dei servizi a titolo di esempio)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Riavviare ogni servizio, ad es.:
systemctl restart plesk-php84-fpm
# Controllare l'orario di avvio dei processi PHP in esecuzione
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Se un dominio gira con Apache e mod_php, riavvii Apache per intero. Se l'orario di avvio di un processo PHP precede l'aggiornamento, quel processo non è ancora stato rinnovato. Altro su questo passaggio alla pagina Riavviare PHP-FPM e tutti i worker.
Protezione transitoria se l'aggiornamento manca ancora
Se per una versione non è ancora disponibile una patch, php.net raccomanda misure transitorie. Non sono una protezione completa. Con Plesk imposti i valori che le applicazioni non devono poter sovrascrivere come php_admin_value nelle direttive FPM aggiuntive del dominio oppure a livello di server nel php.ini della rispettiva versione.
; Esempio di direttive PHP-FPM aggiuntive in Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
Con gli upload, secondo php.net è previsto post_max_size = 32M, con upload_max_filesize inferiore. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. Il limite di memoria tramite memory_limit=-1 va usato solo insieme a un limite a livello di container o cgroup. Poi segue di nuovo il riavvio di tutti i worker. I dettagli sono alla pagina Misure immediate senza patch. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i web server se l'aggiornamento non è possibile subito.
Dopo la patch: conservare i log e cercare tracce
Una patch chiude la vulnerabilità per il futuro. Non rimuove il malware introdotto in precedenza e non dimostra che non sia successo nulla. Conservi quindi i log del web server a partire dal 20/10/2026. Plesk li salva per ogni dominio nella directory logs; in questa situazione non riduca il periodo di conservazione.
Faccia attenzione a file PHP nuovi o modificati nelle directory di upload, attività pianificate sconosciute e nuovi account amministratore. Finora non esistono Indicators of Compromise pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Se trova anomalie, non proceda per conto proprio, ma salvi prima lo stato.
Come aiuta concretamente PHP SOS?
- Rileviamo tutti gli handler PHP del Suo server Plesk, assegniamo i domini e verifichiamo lo stato effettivo dei pacchetti per ogni versione.
- Nell'ambito del nostro servizio di patch PHP installiamo gli aggiornamenti, riavviamo tutti i servizi e documentiamo gli orari di avvio dei processi come prova.
- Dove manca una patch, applichiamo le misure transitorie secondo php.net a livello di server e in modo non sovrascrivibile.
- Salviamo i log e cerchiamo tracce di compromissione; in caso di riscontro con l'incident response.
- Poi rafforziamo il server in modo duraturo e rimuoviamo le versioni di PHP non necessarie.
Domande frequenti
Perché dopo l'aggiornamento Plesk mostra ancora PHP 8.2.34?
Distribuzioni e fornitori a volte applicano le correzioni di sicurezza come backport, senza cambiare il numero di versione. In questi casi contano lo stato dei pacchetti e la conferma del fornitore. La sola indicazione a schermo non prova né la presenza né l'assenza di una patch.
Basta fare clic su Aggiorna nel pannello Plesk?
L'aggiornamento deposita nuovi file, ma i processi PHP in esecuzione continuano a lavorare in memoria con il vecchio codice. Solo dopo il riavvio di tutti i servizi PHP-FPM e del web server il nuovo stato è attivo. Poi verifichi l'orario di avvio dei processi.
Devo aggiornare anche le versioni di PHP che nessun dominio utilizza?
Sì, finché restano installate. Un handler inutilizzato può essere assegnato per errore in seguito o essere raggiungibile tramite ambienti di test. Le versioni non necessarie è meglio disinstallarle del tutto.
Un aggiornamento di WordPress nel Plesk Toolkit aiuta contro PHP2Shell?
No. PHP2Shell riguarda PHP stesso, non il CMS. Aggiornare il CMS resta sensato, ma non chiude questa vulnerabilità.