Immagine di copertina generata con strumenti di intelligenza artificiale.In questa guida
Per mettere al sicuro il sito da PHP2Shell non devi diventare un tecnico: devi sapere quale versione di PHP usa il sito, chi la aggiorna e come ottenere la prova che l'ha fatto. Questa guida ti accompagna in sei passi, con i pannelli degli hosting più diffusi e un testo pronto da inviare al fornitore.
In breve, per chi arriva qui direttamente: il 21 ottobre 2026 il progetto PHP ha corretto due falle critiche (CVE-2026-109618 e CVE-2026-109619) nel motore che esegue i siti WordPress, WooCommerce, PrestaShop e molti altri. Aggiornare WordPress o i plugin non serve: va aggiornato PHP. Se vuoi capire meglio cosa è successo e quanto è grave, leggi prima
Il team di artigiani digitali che crea siti web unici per PMI italiane.
PHP2Shell: cosa è successo e perché riguarda anche il tuo sito
.
→
La regola del laboratorio
l'intervento è finito solo quando hai annotato la versione, ricevuto una conferma scritta e provato che il sito fa ancora il suo lavoro.
Prima di iniziare: chi deve aggiornare il tuo PHP?
La risposta dipende da un solo fatto: che tipo di spazio web hai comprato.
Che spazio web hai
Chi aggiorna PHP
Cosa fai tu
Hosting condiviso o gestito (il caso più comune)
L'hosting
Verifichi, controlli la versione, provi il sito
VPS, server cloud o dedicato
Tu o il tuo tecnico
Fai aggiornare, riavviare e verificare
Non lo so
—
Guarda fattura o area clienti: "VPS", "Cloud" o "Dedicato" vuol dire server tuo
Se c'è un'agenzia o un tecnico che segue il sito, la domanda va girata a loro, ma con la richiesta scritta che trovi al passo 6: "ci pensiamo noi" non è una risposta verificabile.
E se non c'è più nessuno? Capita spesso: chi ha fatto il sito non risponde, gli accessi sono sparsi tra vecchie email. È la situazione per cui esiste la nostra presa in carico del sito: ritroviamo gli accessi, inventariamo cosa c'è e mettiamo in ordine gli arretrati, PHP compreso.
Passo 1 — Scopri quale versione di PHP usa davvero il sito
Se hai WordPress, entra nella Bacheca da un indirizzo che conosci (non da link ricevuti per email) e vai in Strumenti → Salute del sito → Info → Server. Alla voce "Versione PHP" trovi il numero, per esempio 8.3.36.
Annotalo con data e ora. Se non usi WordPress, la versione compare di solito nel pannello dell'hosting, nella sezione dedicata a PHP.
!
Attenzione
il numero che conta è quello usato dal sito. Un tecnico che controlla PHP "da riga di comando" può leggere una versione diversa da quella che serve le pagine: è una delle confusioni segnalate dal CERT-AGID.
Passo 2 — Confronta il numero con le versioni corrette
Se il sito usa PHP…
La versione corretta è almeno…
8.5
8.5.12
8.4
8.4.27
8.3
8.3.36
8.2
8.2.35
8.1 o precedenti
nessuna versione ufficiale: serve una correzione del fornitore o il passaggio a un ramo supportato
Il numero è uguale o superiore alla versione corretta del tuo ramo? Il motore risulta corretto: passa al passo 5.
Il numero è inferiore (per esempio 8.3.30)? Su molti hosting condivisi la correzione può essere installata senza cambiare il numero. Non concludere nulla da solo: vai al passo 3.
Il sito usa 8.1, 8.0, 7.x o precedenti? Il progetto PHP non aggiorna più queste versioni. Leggi il passo 4 con attenzione.
Passo 3 — Controlla cosa ha comunicato il tuo hosting
Ecco cosa hanno pubblicato alcuni degli hosting più usati dalle imprese italiane, verificato il 23 ottobre 2026. Le situazioni cambiano in fretta: in caso di dubbio vale la comunicazione più recente del tuo fornitore.
Hosting
Server condivisi
Cosa fai tu
SiteGround
Aggiornati dal 21/10
Provi il sito
Hostinger
Aggiornati entro il 22/10
Con un VPS aggiorni tu
IONOS
Aggiornati entro il 22/10
Con un VPS aggiorni tu
OVHcloud
Aggiornati in automatico
Con VPS o dedicato aggiorni tu
Aruba
Nessun avviso trovato
Chiedi conferma scritta
Register.it
Nessun avviso trovato
Chiedi conferma scritta
I dettagli, con le fonti e il punto del pannello in cui vedi o cambi la versione:
Hostinger: regole firewall, funzione a rischio disattivata e versioni corrette installate su tutta la piattaforma entro il 22 ottobre; chi ha un VPS deve aggiornare da sé. Per verificare, in PHP Info la Build Date deve essere del 21 ottobre 2026 o successiva. Versione: Siti web → Dashboard → PHP Configuration.
OVHcloud: hosting web condiviso aggiornato automaticamente; per VPS e server dedicati servono copia di sicurezza, aggiornamento, riavvio e verifica a cura del cliente. Sotto PHP 7.4 non è prevista alcuna correzione. Versione: spazio cliente → Web Cloud → Hosting → configurazione.
Aruba: al 23 ottobre non abbiamo trovato una comunicazione pubblica specifica su PHP2Shell; la pagina sicurezza indica patch gestite sui servizi Linux. Controlla notifiche e area clienti, poi invia all'assistenza il testo del passo 6. Versione: pannello → Strumenti e Impostazioni → Gestione PHP.
Register.it: al 23 ottobre non abbiamo trovato una comunicazione pubblica specifica su PHP2Shell. Come per Aruba: notifiche, area clienti, richiesta scritta. Versione: cPanel → Select PHP Version, oppure pannello Linux → Gestione versione PHP.
"Non abbiamo trovato una comunicazione" non significa che il fornitore non sia intervenuto: significa che la prova va chiesta.
Passo 4 — Se il sito usa una versione vecchia, pianifica il passaggio
Se il passo 1 ti ha restituito 8.1 o una versione precedente, il problema è più grande di PHP2Shell: quella versione non riceve più correzioni dal progetto PHP, e resterà scoperta anche alla prossima falla. Anche la 8.2 smetterà di ricevere aggiornamenti il 31 dicembre 2026: se devi cambiare, punta almeno alla 8.3, la versione che WooCommerce raccomanda.
Il cambio di versione si fa quasi sempre con un clic dal pannello (vedi i percorsi al passo 3), ma un clic può anche fermare un sito con plugin vecchi. Procedi così:
Copia di sicurezza di file e database, e verifica di saperla ripristinare.
Prova su una copia del sito (molti hosting la chiamano staging), se il tuo pacchetto la offre.
Cambia la versione dal pannello, in un orario di basso traffico.
Apri subito le pagine principali. Se compare un errore, torna alla versione precedente dallo stesso pannello: la modifica è reversibile e non tocca i tuoi file.
Se il sito funziona solo con la versione vecchia, quello è il segnale che qualche plugin o il tema vanno sostituiti: è un lavoro da affidare a un tecnico, non da rimandare.
!
Controllo di rischio
il sintomo più comune dopo un cambio di versione è il messaggio «Si è verificato un errore critico sul tuo sito web». Non è un attacco: quasi sempre è un plugin incompatibile. Se lo vedi, torna alla versione precedente e leggi cosa significa davvero l'errore critico di WordPress.
Preferisci non farlo da solo? È un lavoro tipico del nostro intervento WordPress a prezzo fisso: copia di sicurezza prima di toccare, cambio di versione, sostituzione o aggiornamento di ciò che si rompe e una spiegazione scritta di cosa abbiamo fatto. Senza abbonamento, e con il prezzo noto prima di iniziare.
Passo 5 — Prova i percorsi che ti fanno lavorare
Dopo ogni intervento sul motore, controlla che il sito non solo si apra, ma faccia il suo lavoro:
invia una richiesta dal modulo contatti e verifica che arrivi nella casella giusta;
se vendi online, porta un prodotto fino alla pagina di pagamento (o fai un ordine di prova se il negozio lo prevede);
controlla che partano le email automatiche (conferma d'ordine, registrazione, recupero password);
entra nell'area riservata e, se ci sono, prova prenotazioni e calendario.
Un sito può rispondere bene in home page e avere il checkout rotto: è il guasto che costa di più ed è il primo che sfugge. Noi lo chiamiamo controllo dei percorsi critici, ed è la parte del nostro lavoro a cui teniamo di più: non "il sito è online", ma "un cliente riesce davvero a scriverti o a comprare".
Passo 6 — Chiedi e conserva una conferma scritta
I sei passi della guida: l'ultimo, la conferma scritta, è quello che ti resta in mano. Immagine generata con strumenti di intelligenza artificiale.
Che lo faccia l'hosting, un'agenzia o un tecnico, alla fine deve restarti una risposta con dei fatti. Puoi copiare questo testo così com'è:
N
Testo da copiare e inviare
Buongiorno, per il sito [indirizzo del sito] vi chiedo di confermare per iscritto, in merito alle vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 (PHP2Shell):
quale versione di PHP usa il sito web (non la riga di comando) e in quale modalità viene eseguita;
se è stata installata la versione corretta o una correzione equivalente del fornitore, con data e ora;
se i servizi PHP e il web server sono stati riavviati dopo l'aggiornamento;
se, nel caso di una versione 8.1 o precedente, è prevista una correzione o il passaggio a una versione supportata, e con quale scadenza;
se nei registri del server sono emersi segnali anomali.
Grazie.
Archivia la risposta insieme alla versione che hai annotato al passo 1. Se un giorno qualcuno ti chiederà "eravate protetti?", avrai una risposta.
Se hai un VPS o un server tuo: cosa girare al tecnico
Questa parte non è da fare da soli se non si amministrano server. Al tecnico basta sapere cosa ci si aspetta:
aggiornare i pacchetti PHP della distribuzione o del pannello (cPanel, Plesk, CloudLinux pubblicano pacchetti corretti con numeri a volte diversi da quelli ufficiali);
riavviare PHP-FPM o Apache: senza riavvio i processi continuano a usare il codice vecchio;
verificare la versione effettivamente servita dal sito, non soltanto quella da riga di comando;
controllare i registri del web server cercando errori di memoria esaurita, crash o riavvii inattesi, come indicato dal CERT-AGID.
Se l'aggiornamento non è subito possibile, PHP e CERT-AGID descrivono mitigazioni temporanee (per esempio disattivare session.upload_progress a livello di configurazione e limitare le richieste dal web server), ma sono esplicite: riducono il rischio, non lo eliminano. Lo CSIRT Italia, come WordPress e WooCommerce, indica anche l'ultima risorsa: se non si può aggiornare subito, valutare di sospendere l'accesso al sito finché non è protetto.
Se il server è tuo e non hai un tecnico di riferimento, scrivici: valutiamo la situazione e ti diciamo con chiarezza se possiamo occuparcene noi o a chi conviene rivolgersi.
Cosa non fare
Non lanciare scanner trovati online contro il sito. Il CERT-AGID ha segnalato strumenti di verifica, ma quello "attivo" invia richieste anomale che possono causare errori: va usato solo su sistemi propri, da chi sa leggerne il risultato. Quello "passivo" spesso risponde "non determinabile", perché molti server non dichiarano la versione.
Non considerare il firewall una cura. Regole firewall e filtri aiutano mentre si aggiorna, non sostituiscono l'aggiornamento.
Non cercare di correggere dal codice del sito. Le impostazioni scritte nel codice dell'applicazione arrivano troppo tardi per questa falla: si interviene nella configurazione del server.
Non dedurre di essere stati attaccati solo perché la versione era vulnerabile. Una versione esposta è un rischio, non la prova di un attacco riuscito. Se però emergono segnali anomali (account sconosciuti, file mai visti, reindirizzamenti strani), serve un'analisi vera: parti da cosa fare con un sito WordPress hackerato.
Domande frequenti
Il mio hosting ha detto che è tutto a posto. Devo fare altro?
Verifica che la comunicazione riguardi il tuo tipo di servizio (hosting condiviso o VPS) e la tua versione di PHP, poi prova i percorsi del passo 5. Se hai solo una mail generica, chiedi comunque la conferma del passo 6: costa due minuti.
Il numero di versione è rimasto uguale. Vuol dire che non hanno aggiornato?
Non necessariamente. Alcuni fornitori (per esempio chi usa CloudLinux) installano la correzione senza cambiare il numero mostrato. Per questo la richiesta scritta chiede "versione corretta o correzione equivalente, con data".
Posso semplicemente passare all'ultima versione di PHP?
Spesso è la scelta giusta, ma non alla cieca: segui il passo 4. Più il sito è vecchio, più è probabile che un plugin non regga il salto.
Uso un costruttore di siti come Wix o Shopify: devo fare qualcosa?
Su queste piattaforme il server lo gestisce interamente il fornitore e non hai accesso a PHP. Se hai dubbi, consulta le comunicazioni ufficiali della piattaforma.
Fatto oggi. E la prossima volta?
Se hai seguito i sei passi, oggi hai chiuso PHP2Shell. La prossima falla, però, non arriverà con un articolo che ti spiega cosa fare.
qualcuno se ne accorge per te. La sorveglianza delle vulnerabilità copre anche il livello sotto il CMS, e la domanda del passo 6 al fornitore la facciamo noi;
si verifica il motore, non solo il pannello. Controlliamo la versione che serve davvero il sito e, se serve cambiarla, lo facciamo con una copia di sicurezza prima di procedere e un modo pronto per tornare indietro;
si provano i percorsi che contano, con la frequenza prevista dal piano;
ti resta una traccia: un riepilogo di cosa è stato fatto e verificato;
un fornitore solo, se lo vuoi: con l'hosting gestito opzionale parliamo noi con il fornitore quando c'è un problema, e il dominio resta intestato a te.
Cosa non possiamo promettere: che non esisterà mai più una vulnerabilità, né di sostituire l'hosting nelle sue responsabilità. Possiamo ridurre il tempo tra l'avviso e la verifica e far sì che qualcuno ne risponda davvero.
Preferisci che il cambio di versione lo facciamo noi?
Copia di sicurezza prima di toccare, aggiornamento, controllo delle pagine principali e una spiegazione scritta di cosa abbiamo fatto. Prezzo noto prima di iniziare, senza abbonamento.
