Situazione attuale: PHP2Shell. Due vulnerabilità critiche di PHP (CVSS 9,2) consentono codice dannoso senza autenticazione. Patch dal 21/10/2026.Che cosa fare ora →

PHP2Shell: 15 domande dei clienti di hosting

Il Suo sito è presso l'hoster e vuole sapere cosa deve fare personalmente con PHP2Shell? Ecco le 15 domande più frequenti con risposte brevi.

Stato 5 min di letturaSituazione e inquadramento

In breve: cosa fare come cliente di hosting con la vulnerabilità PHP2Shell? L'aggiornamento di PHP di norma non deve installarlo Lei: nello shared hosting se ne occupa l'hoster. I Suoi compiti sono altri: ottenere una conferma scritta dello stato della patch, scegliere nel menu clienti una versione di PHP supportata e verificare il Suo sito per anomalie. Le 15 domande più frequenti in merito trovano in questo articolo una risposta breve, una dopo l'altra.

Vulnerabilità PHP per i clienti di hosting: sono interessato, cosa faccio?

Dal 21 ottobre 2026 riceviamo molte domande da aziende il cui sito è presso un hoster. La maggior parte riguarda gli stessi punti. Chi desidera leggere più a fondo le responsabilità le trova in Shared hosting: cosa fa l'hoster e cosa deve fare Lei.

1. Il mio sito è davvero interessato?

Se il Suo sito gira con WordPress, Shopware, TYPO3, Joomla, Contao o un altro sistema PHP, il server sottostante può essere interessato. Le pagine puramente HTML senza PHP non lo sono. Nel dubbio aiuta uno sguardo al menu clienti: se c'è un'impostazione per la versione di PHP, Lei usa PHP.

2. Qual è la differenza tra shared hosting e server proprio?

Con lo shared hosting condivide con altri clienti un server gestito dall'hoster; l'hoster cura PHP. Con un root server o vServer proprio è responsabile Lei stesso. Con un server gestito il contratto regola chi installa gli aggiornamenti.

3. Il mio hoster ha inviato una mail a tutti i clienti. Devo fare ancora qualcosa?

Legga con attenzione cosa c'è scritto. Una mail circolare spesso conferma soltanto che l'hoster «sta lavorando sul tema». A Lei serve un'affermazione sul Suo pacchetto: ramo PHP, stato della patch, momento e riavvio.

Responsabilità e aggiornamento

4. L'hoster installa l'aggiornamento in automatico?

Di norma sì, per le versioni di PHP che offre sui suoi server. Se sia già avvenuto e se siano coperte anche le versioni più vecchie varia da hoster a hoster. Chieda.

5. Il mio menu clienti mostra un vecchio numero di versione. Sono privo di protezione?

Non necessariamente. Molti hoster inseriscono le correzioni come backport, e il numero resta allora lo stesso. Plesk, ad esempio, può continuare a mostrare 8.2.34 anche se l'errore è corretto. Fa fede la conferma dell'hoster.

6. Uso ancora PHP 7.4 o 8.1. E ora?

Questi rami non ricevono più aggiornamenti ufficiali dal progetto PHP. Alcuni hoster forniscono correzioni proprie, altri no. Lo chiarisca per iscritto e pianifichi il passaggio a un ramo supportato. Prima verifichi nei requisiti di sistema del Suo CMS quali versioni di PHP supporta.

7. Posso cambiare io stesso la versione di PHP?

Con la maggior parte degli hoster sì, nel menu clienti. Come si fa e a che cosa fare attenzione prima lo descrive l'articolo Cambiare la versione di PHP nell'area clienti dell'hosting. Prima faccia un backup.

8. Aiuta aggiornare WordPress o i plugin?

Contro PHP2Shell no, perché la vulnerabilità sta in PHP. Gli aggiornamenti del CMS sono comunque sensati, perché chiudono altre vulnerabilità.

Verificare e documentare

9. Come ottengo una prova dall'hoster?

Con una richiesta scritta che chiede indicazioni concrete: stato dei pacchetti per ogni ramo PHP, data di installazione, riavvio di tutti i processi PHP. Un modello da copiare lo offre la guida Richiedere la conferma dell'aggiornamento PHP all'hoster.

10. Posso impostare le misure transitorie tramite .user.ini?

No. php.net sconsiglia espressamente di impostare le impostazioni transitorie tramite ini_set() o .user.ini. Vanno nella configurazione del server, e nello shared hosting la gestisce l'hoster.

11. Il mio sito è stato offline per poco. Sono stato violato?

Non necessariamente. Alcuni hoster hanno spento siti in via precauzionale o riavviato server. Chieda il motivo prima di trarre conclusioni.

12. Da che cosa riconosco che il mio sito è stato attaccato?

Possibili indizi sono account amministratore sconosciuti, nuovi file PHP nella cartella di upload, reindirizzamenti a siti estranei, pagine estranee nell'indice di Google o avvisi nella Search Console. Chieda all'hoster di conservare i log di accesso dal 20 ottobre.

Quando qualcosa non torna

13. L'hoster non risponde o risponde in modo evasivo. Che fare?

Chieda per iscritto e fissi un termine adeguato. Se la risposta non arriva, dovrebbe trattare il server come non verificato e valutare di portare temporaneamente il sito su una pagina di emergenza statica.

14. Devo cambiare hoster?

Un cambio nel pieno della situazione crea rischi propri. Ha senso se l'hoster non dà in modo permanente alcuna informazione o continua a gestire vecchie versioni di PHP senza correzione. A che cosa fare attenzione lo descrive Cambiare hoster dopo un incidente.

15. Devo notificare qualcosa?

Se vi sono indizi di un attacco e possono essere coinvolti dati personali, può sussistere un obbligo di notifica ai sensi del GDPR, di norma entro 72 ore. Lo chiarisca con il Suo responsabile della protezione dei dati o con un avvocato. Questa non è consulenza legale.

La Sua breve checklist

  1. Chiedere per iscritto all'hoster stato della patch e riavvio.
  2. Verificare la versione di PHP nel menu clienti, sostituire i rami obsoleti.
  3. Esaminare gli account amministratore e la cartella di upload.
  4. Verificare avvisi nella Search Console.
  5. In caso di anomalie chiedere aiuto prima di cancellare file.

Come aiuta concretamente PHP SOS?

  • Chiarimento con l'hoster: formuliamo la richiesta o conduciamo il colloquio e valutiamo la risposta.
  • Verifica del sito: cerchiamo tracce in file, database e account, per quanto il pacchetto di hosting lo consenta.
  • Bonifica: se troviamo codice dannoso lo rimuoviamo e cambiamo tutti gli accessi.
  • Documentazione: riceve lo stato per iscritto.

In caso di sospetto concreto aiuta il pronto intervento per siti web violati.

Conclusione

Come cliente di hosting, con PHP2Shell Lei non porta il peso dell'aggiornamento, ma la responsabilità del Suo sito. La maggior parte delle domande si risolve con una chiara risposta scritta dell'hoster. Ciò che resta dopo è lo sguardo al proprio sito: account, file, segnalazioni di Google. Chi ha fatto entrambe le cose ha fatto la sua parte e, nel dubbio, può dimostrare di aver agito con diligenza.

Domande frequenti

Chi è responsabile dell'aggiornamento di PHP nel web hosting?

Nello shared hosting di norma l'hoster, perché gestisce il server e l'installazione di PHP. Lei è responsabile del Suo sito, dei Suoi accessi e della scelta della versione di PHP nel menu clienti. Con i server gestiti il contratto regola la ripartizione.

Perché il mio hoster mostra una versione vecchia di PHP?

Molti hoster e distribuzioni integrano la correzione come backport nella versione esistente. Il numero resta allora lo stesso, anche se la vulnerabilità è chiusa. Si affidi quindi a una conferma scritta dell'hoster, non alla visualizzazione.

Cosa posso verificare personalmente come cliente di hosting?

Può controllare la versione di PHP impostata nel menu clienti, esaminare gli account amministratore del Suo CMS, cercare file sconosciuti nella cartella di upload e verificare avvisi nella Search Console. Lo stato della patch del server stesso lo può documentare solo l'hoster.

Un'impostazione del firewall nel pacchetto di hosting aiuta?

Le regole firewall dell'hoster o di un servizio a monte possono ridurre il rischio. Non sostituiscono però l'aggiornamento di PHP sul server. Chieda quindi sempre prima dell'aggiornamento.

Fonti

Contatto immediato

Ogni ora conta. Ci scriva adesso.

Descriva brevemente sistema, versione di PHP e quanto osservato. Ci faremo sentire, chiariremo la situazione e lavoreremo da remoto fino alla chiusura e alla documentazione dell'incidente.

Aiuto immediato