In breve: davanti a una vulnerabilità PHP come PHP2Shell, nel web hosting l'aggiornamento di PHP spetta all'hoster, non a Lei. Il Suo compito è ottenere una conferma scritta, scegliere nel menu cliente una versione di PHP supportata e controllare il Suo sito alla ricerca di tracce di un attacco. Una patch dell'hoster non rimuove il malware che fosse già arrivato prima sul Suo sito.
La situazione in parole semplici
PHP è il linguaggio di programmazione con cui girano la maggior parte dei siti web, degli shop e dei CMS come WordPress. PHP2Shell indica due errori critici in PHP stesso (CVE-2026-109618 e CVE-2026-109619). Gli aggressori possono così eseguire codice proprio sul server senza password. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 (arancione) e raccomanda un aggiornamento immediato.
Nello shared hosting molti clienti condividono un server. La tecnica sottostante, cioè sistema operativo, web server e PHP, è gestita dall'hoster. Lei gestisce soltanto il Suo sito, il database e gli accessi. Per questo non può installare da solo l'aggiornamento di PHP e non deve farlo.
Hosting web e vulnerabilità PHP: chi è responsabile?
La ripartizione deriva dal Suo contratto. Nella maggior parte delle tariffe vale grosso modo la seguente ripartizione:
| Compito | Hoster | Lei come cliente |
|---|---|---|
| Aggiornare i pacchetti PHP | sì | no |
| Riavviare i processi PHP | sì | no |
| Impostare valori transitori a livello di server | sì | no |
| Scegliere la versione di PHP del sito | la mette a disposizione | la sceglie |
| Aggiornare CMS, plugin, temi | no | sì |
| Credenziali e account amministratore | no | sì |
| Verificare il sito alla ricerca di codice dannoso | in parte | sì |
| Valutazione sotto il profilo della protezione dei dati | no | sì |
Importante è l'ultima riga: se sul Suo sito si verifica un incidente con dati personali, di norma responsabile è Lei come gestore, non l'hoster. Maggiori informazioni alla pagina Obbligo di notifica GDPR.
Che cosa dovrebbe fare Lei adesso
1. Ottenere la conferma. Chieda per iscritto al Suo hoster se le versioni di PHP del Suo pacchetto sono protette da entrambe le CVE, da quando, e se tutti i processi PHP sono stati riavviati. Un modello pronto si trova alla pagina Chiedere all'hoster lo stato della patch. Non si stupisca se nel menu cliente compare ancora un numero di versione più vecchio come 8.2.34: alcuni fornitori distribuiscono le correzioni come backport, senza che il numero cambi.
2. Verificare la versione di PHP. Controlli nel menu cliente quale versione di PHP usa il Suo sito. Per PHP 8.1 e precedenti il progetto PHP non rilascia più aggiornamenti ufficiali. PHP 8.2 raggiunge la fine del supporto il 31/12/2026. Se il Suo CMS supporta una versione più recente lo verifichi nei requisiti di sistema del produttore, ad esempio su wordpress.org.
3. Controllare il sito. Faccia attenzione ad account amministratore sconosciuti, reindirizzamenti inattesi, file estranei nell'accesso FTP e avvisi in Google Search Console. Un elenco dei segnali tipici si trova alla pagina Sono già stato compromesso?.
4. Creare un backup. Scarichi un backup aggiornato di file e database e lo conservi separatamente. Chieda inoltre all'hoster di conservare i log di accesso del Suo pacchetto a partire dal 20/10/2026.
Dopo la conferma dell'hoster, cambi in via precauzionale le password del menu cliente, di FTP/SFTP, del database e degli amministratori del CMS e, dove possibile, attivi l'autenticazione a due fattori.
Che cosa non può risolvere da solo nello shared hosting
Le misure transitorie raccomandate da php.net, ad esempio session.upload_progress.enabled=0, sono efficaci solo se impostate nella configurazione del server. Secondo php.net, una voce in .user.ini o tramite ini_set() nel codice non basta. Anche i limiti di memoria a livello di cgroup e il riavvio dei processi PHP sono di competenza dell'hoster.
Se il Suo hoster non risponde o risponde in modo evasivo, ha tre possibilità: sollecitare e fissare un termine, mettere temporaneamente il sito in modalità manutenzione oppure passare a un fornitore con una posizione chiara. Il BSI raccomanda di scollegare temporaneamente dalla rete i web server se un aggiornamento non è possibile subito.
Verifichi inoltre se la Sua tariffa è ancora attuale. I pacchetti che girano invariati da molti anni a volte si trovano su generazioni di server più vecchie, con versioni di PHP più vecchie che l'hoster cura solo in misura limitata. Passare a una tariffa attuale dello stesso fornitore richiede spesso poco impegno e porta con sé versioni di PHP più recenti. Lo chieda se la risposta sullo stato della patch non è soddisfacente.
Se il sito è già anomalo
Una patch presso l'hoster chiude la vulnerabilità per il futuro. Non rimuove però una backdoor inserita prima dagli aggressori e non prova che prima non sia successo nulla. Se trova anomalie, non cancelli file a caso. Salvi prima lo stato, in modo che la causa resti ricostruibile in seguito.
Come aiuta concretamente PHP SOS?
- Formuliamo con Lei la richiesta all'hoster e valutiamo tecnicamente la sua risposta.
- Verifichiamo il Suo sito alla ricerca di webshell, account estranei e file manipolati e, in caso di riscontro, lo bonifichiamo tramite la nostra rimozione del malware.
- In caso di sospetto acuto ci occupiamo dell'assistenza di emergenza per siti web violati con acquisizione delle prove.
- La aiutiamo nella scelta di una versione di PHP adatta e testiamo il sito dopo il cambio.
Domande frequenti
Come cliente di hosting devo aggiornare PHP da solo?
Di norma no, perché nello shared hosting PHP fa parte della piattaforma dell'hoster. Spesso però può scegliere la versione di PHP nel menu cliente. Se vi compare una versione senza aggiornamenti ufficiali, dovrebbe cambiarla o chiedere all'hoster come la mette in sicurezza.
Il mio sito è offline. Sono stato violato?
Non necessariamente. Alcuni fornitori hanno messo i siti offline in via precauzionale per chiudere la vulnerabilità. Chieda all'hoster il motivo e si faccia confermare se esistono indizi di un attacco al Suo pacchetto.
Posso impostare da solo le misure transitorie in .user.ini?
Per session.upload_progress.enabled php.net indica espressamente che .user.ini e ini_set() non bastano. Questa impostazione deve essere fatta dall'hoster nella configurazione del server.
Che cosa dovrei avere per iscritto dall'hoster?
Una conferma che le versioni di PHP del Suo pacchetto sono protette da CVE-2026-109618 e CVE-2026-109619, da quando vale e che i processi PHP sono stati riavviati. Conservi questa risposta insieme alla Sua documentazione.