# Server Plesk: verificare e aggiornare le versioni di PHP

> Aggiornamento PHP su Plesk dopo PHP2Shell: come verificare handler, pacchetti e backport, riavviare tutti i servizi PHP-FPM e documentare la patch.

Fonte: https://phpsos.de/it/server/plesk/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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.

> **Importante:**
> 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.

```bash
# 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.

```bash
# 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](https://phpsos.de/it/ratgeber/hoster-patch-status-erfragen/).

## 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.

```bash
# 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](https://phpsos.de/it/php2shell/php-fpm-neustart/).

## 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.

```ini
; 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](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/it/leistungen/php-patch-service/) 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](https://phpsos.de/it/leistungen/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à.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versioni supportate](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)