In breve: dopo PHP2Shell la sola versione di PHP visualizzata dimostra poco, perché gli hoster spesso applicano le correzioni come backport. Chieda quindi una conferma scritta dell'aggiornamento PHP all'hoster: stato dei pacchetti per ogni ramo PHP, momento dell'installazione e riavvio di tutti i processi PHP. Un modello da copiare si trova più sotto.
Perché proprio ora conta una conferma scritta
Il 21/10/2026 il progetto PHP ha pubblicato le patch per due vulnerabilità critiche note con il nome PHP2Shell. Entrambe consentono l'esecuzione di codice dannoso da remoto senza autenticazione. Il BSI (Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 / arancione e raccomanda l'aggiornamento immediato.
Chi gestisce il proprio sito presso un hoster spesso non può installare l'aggiornamento da solo. Al tempo stesso, come gestore, Lei è responsabile dei dati dei Suoi clienti. Una conferma scritta e concreta dell'hoster è quindi più di una formalità. È un tassello della Sua documentazione, ad esempio nei confronti dei responsabili della protezione dei dati, degli assicuratori o della direzione.
Si aggiunge che una patch non rimuove il malware introdotto in precedenza. Secondo i media, già il 17/10 era stato osservato un primo tentativo di attacco. Il momento esatto in cui il Suo server è stato protetto è quindi importante per stabilire se debba proseguire i controlli.
Perché la versione di PHP visualizzata non basta
Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Molte distribuzioni e molti hoster però riprendono la correzione come backport nel proprio pacchetto. In tal caso un'interfaccia come Plesk continua a mostrare 8.2.34 anche se il server è aggiornato.
Al contrario, anche un numero di versione corretto può ingannare. I file nuovi da soli non proteggono finché in memoria girano vecchi processi PHP. Solo dopo il riavvio di tutti i worker lo stato nuovo è attivo. Maggiori informazioni nell'articolo Verificare correttamente la versione di PHP e lo stato delle patch.
| Dichiarazione dell'hoster | Che cosa dimostra | Che cosa manca |
|---|---|---|
| «Tutti i sistemi sono aggiornati.» | poco | versione o stato dei pacchetti, data, riavvio |
| «PHP 8.3.36 è installato.» | versione | data, riavvio, server interessati |
| «Backport nel pacchetto xy, riavvio il …» | patch e attivazione | se del caso, indicazioni su PHP 8.1 e precedenti |
Quali informazioni servono dall'hoster
Chieda risposte a questi punti, possibilmente per ogni sito o contratto:
- Quali rami e versioni di PHP sono attivi per i Suoi siti, anche quelli più vecchi che girano solo per singole directory?
- Le correzioni per CVE-2026-109618 e CVE-2026-109619 sono incluse, come versione ufficiale o come backport?
- Quando è stato installato l'aggiornamento e quando sono stati riavviati tutti i processi PHP (pool FPM, Apache, LiteSpeed)?
session.upload_progress.enabledè disattivato a causa di CVE-2026-115560?- Quale modalità di esecuzione usa il Suo piano, ad esempio PHP-FPM o Apache con mod_php? Con mod_php il team PHP vede il rischio più alto.
- Quali log di accesso e di errore a partire dal 20/10/2026 vengono conservati e come può ottenerli?
Se un sito gira ancora su PHP 8.1 o precedenti, lo chieda separatamente. Per questi rami non esistono più aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1.
Modello: richiedere la conferma dell'aggiornamento PHP all'hoster
Copi il testo in un ticket di supporto o in un'e-mail al Suo hoster. Completi le indicazioni tra parentesi quadre.
Oggetto: Richiesta di conferma dello stato delle patch PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Buongiorno,
gestiamo presso di Voi i seguenti siti web / contratti:
[numero cliente, contratto, domini]
In relazione alle vulnerabilità PHP CVE-2026-109618 e
CVE-2026-109619 (PHP2Shell, patch del 21.10.2026) nonché all'avviso
su CVE-2026-115560 del 23.10.2026, Vi chiediamo una
conferma scritta dei seguenti punti:
1. Quali versioni di PHP o stati dei pacchetti sono attivi per i nostri siti web?
2. Contengono le correzioni (versione ufficiale o backport)?
3. Data e ora dell'installazione.
4. Data e ora del riavvio di tutti i processi PHP (FPM, Apache,
LiteSpeed o simili).
5. session.upload_progress.enabled è disattivato lato server?
6. Quale modalità di esecuzione di PHP viene utilizzata (ad es. PHP-FPM, mod_php)?
7. I log di accesso e di errore vengono conservati a partire dal 20.10.2026 e
come possiamo ottenerli?
8. Se un sito web usa ancora PHP 8.1 o una versione precedente: quale protezione
è prevista in tal caso e quale migrazione consigliate?
Abbiamo bisogno di queste informazioni per la nostra documentazione interna.
Grazie e cordiali saluti
[Nome, azienda, funzione]
Valutare correttamente la risposta e verificare da soli
Una buona risposta indica stati, date e orari concreti. Formulazioni generiche come «abbiamo reagito» non bastano per il Suo fascicolo. In tal caso chieda con cortesia i punti mancanti.
Se il Suo piano lo consente, verifichi anche da solo. Con accesso SSH di solito bastano questi comandi:
# Versione della riga di comando (può differire dalla versione web)
php -v
# Stato dei pacchetti su Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Stato dei pacchetti su RHEL, Alma, Rocky
rpm -qa | grep -i php
# Da quando girano i processi PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Se l'avvio dei processi PHP risale a prima della data di installazione confermata, il riavvio non è stato completo.
Se l'hoster non risponde o risponde in modo evasivo
Se la risposta non arriva o mancano le indicazioni decisive, non consideri chiarita la situazione. Il BSI raccomanda di scollegare temporaneamente i server web dalla rete quando un aggiornamento non è possibile subito. Se ciò sia proporzionato per il Suo sito lo decide la direzione, idealmente per iscritto e con data.
In parallelo conviene cercare possibili tracce di un attacco, perché il momento della patch resta incerto. Indizi si trovano nell'articolo Sono già stato compromesso?. Senza accesso SSH la conferma scritta resta la Sua prova più importante. Quali obblighi spettano all'hoster e quali a Lei lo spiega la pagina Shared hosting: che cosa fa l'hoster; per i server gestiti è utile Server gestito: chiarire le responsabilità.
Conservi richiesta, risposta e risultati dei Suoi controlli, con data, in una cartella. Questo fascicolo aiuta in seguito in caso di domande di assicuratori o responsabili della protezione dei dati.
Come aiuta concretamente PHP SOS?
- Formuliamo con Lei la richiesta all'hoster e valutiamo la risposta dal punto di vista tecnico.
- Dove c'è accesso, verifichiamo noi stessi stato dei pacchetti, modalità di esecuzione attiva e riavvio dei processi PHP.
- Se restano lacune, adottiamo misure provvisorie o pianifichiamo il passaggio a una versione supportata.
- Registriamo risultato e date in un documento di prova che Lei può inoltrare internamente.
Come si svolgono l'aggiornamento con riavvio e la prova è descritto nel nostro Servizio patch PHP.
Domande frequenti
Basta che il mio hoster scriva che è tutto aggiornato?
Per la Sua documentazione, di solito no. Chieda indicazioni concrete: stato dei pacchetti o versione per ogni ramo PHP, data dell'installazione e data del riavvio di tutti i processi PHP. Solo così potrà circoscrivere la finestra di vulnerabilità.
Perché la mia interfaccia di hosting mostra ancora PHP 8.2.34?
Distribuzioni e hoster applicano talvolta le correzioni di sicurezza come backport, senza modificare il numero di versione. Plesk può quindi continuare a mostrare 8.2.34 anche se il server è aggiornato. Solo la conferma del fornitore sullo stato dei pacchetti dà chiarezza.
Che cosa faccio se l'hoster non risponde?
Documenti la Sua richiesta con la data e sollecitiamo dopo un tempo ragionevole. Verifichi nel frattempo se può adottare da solo misure provvisorie e concordi con la direzione se il sito debba restare offline fino a chiarimento, come il BSI raccomanda per i server non aggiornati.
Un aggiornamento di WordPress o dello shop chiude anch'esso la vulnerabilità?
No. PHP2Shell si trova in PHP stesso. Un aggiornamento del CMS o del software dello shop non cambia nulla all'interprete PHP che gira sul server.