PHP2Shell: chi aggiorna il PHP del tuo sito?

Mercoledì 21 ottobre 2026, mattina. Ozone Coffee, Leonard Street, Shoreditch. Mattoni a vista, lampade di rame che pendono sopra il bancone, sgabelli verdi, assi di legno chiaro sotto le suole. L'aria sa di caffè appena tostato, perché la torrefazione è lì, a pochi metri dal tavolo dove mi siedo quando voglio un caffè fatto bene prima di salire in ufficio.

Il telefono vibra. È l'app del mio hosting provider, quello dove tengo siti miei e di clienti. Una notifica che parla di vulnerabilità critiche in PHP.

La leggo in piedi, con la tazza in mano. Capisco che è seria. Poi faccio una cosa di cui oggi ti parlo volentieri, perché non mi fa fare una gran figura: rimando. Mi dico che è meglio guardarla con calma, dalla scrivania, con la testa libera. Sono circa due ore. Rientro in ufficio, rispondo alle email, organizzo la giornata. Solo dopo apro il terminale e comincio a capire.

Racconto questa esitazione perché è quella che stanno avendo, in questo momento, migliaia di titolari di siti web. Con una differenza: io sapevo cosa cercare e chi chiamare. Berto, che ha un sito da quindici anni e lo ha sempre visto "funzionare", di solito non sa nemmeno che esista una cosa chiamata PHP.

Questo articolo parte da lì. Da una domanda che il tuo preventivo non contiene e che il tuo hosting non ti ha mai fatto: il PHP del tuo sito, chi lo aggiorna?

In breve

• PHP2Shell è il nome dato a due vulnerabilità del linguaggio PHP (CVE-2026-109618 e CVE-2026-109619, gravità 9,2 su 10 nella scala CVSS). Sono nel PHP, non in WordPress, Joomla o Drupal.
• Permettono a un attaccante di eseguire codice sul server: in gergo, esecuzione di codice remota (RCE).
• Le correzioni sono uscite il 21 ottobre 2026 nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• La domanda giusta non è "il mio sito è aggiornato?", ma "chi aggiorna il PHP e come faccio a verificarlo?".
• 2FA, regole nel .htaccess e firewall nel sito sono utili. Non sostituiscono la patch.
• Aggiornare PHP può rompere il sito: è la parte di cui nessuno parla, e quella che mi ha occupato di più.

Cosa è successo, in ordine

Metto in fila le date, perché in questi giorni se ne leggono di confuse.

• 20 ottobre: anteprima dell'annuncio da parte del progetto PHP.
• 21 ottobre: escono le versioni corrette. Lo stesso giorno, dalle 14:19 UTC (l'ora di Greenwich), la società di sicurezza watchTowr osserva tentativi di sfruttamento. Il NCSC, il centro nazionale di cybersicurezza britannico, pubblica il suo avviso.
• 23 ottobre: PHP segnala una terza falla, separata dalle prime due. Ne parlo più avanti, perché è la cosa più facile da fraintendere.
• 25 ottobre: allerta del CSIRT Italia, il team nazionale di risposta agli incidenti informatici. Nella sua rilevazione: 741.523 servizi esposti, di cui 285.149 potenzialmente vulnerabili. Tra quelli di cui si riesce a identificare la versione, l'81,9% risulta vulnerabile. Rapportato al totale, i potenzialmente vulnerabili sono circa il 38% (calcolo mio, non loro).
• 26 ottobre: la CISA americana inserisce le falle nel suo catalogo delle vulnerabilità sfruttate attivamente (KEV, Known Exploited Vulnerabilities).

Un dato per capire la scala: secondo W3Techs, a metà luglio 2026 il PHP girava sul 70,8% dei siti di cui si conosce il linguaggio lato server. Non è un angolo del web. È il pavimento.

Cosa sono, senza tutorial per attaccanti

Ti spiego il meccanismo con una metafora che conosco bene. Immagina la cucina di un ristorante di Portici durante il servizio. Gli ordini arrivano uno dietro l'altro, il cuoco lavora sullo stesso piano, usa le stesse padelle. Se una comanda arriva a metà, scritta male, e il cuoco la finisce comunque, il piatto esce sbagliato. Se una padella non viene lavata e la comanda dopo la ritrova sporca, il cliente successivo mangia quello che ha cucinato il precedente.

Le due falle funzionano un po' così.

• CVE-2026-109618: quando il PHP resta senza memoria, la gestione di quel caso interrompe l'elaborazione lasciando i dati della richiesta in uno stato incompleto.
• CVE-2026-109619: dati che appartengono a una richiesta sopravvivono dopo che la memoria è stata liberata, e vengono riutilizzati da una richiesta successiva sullo stesso processo.

Mi fermo qui. Non perché non sappia andare oltre, ma perché oltre c'è la parte che serve a chi attacca, non a chi difende.

Quello che ti serve sapere:

• Il problema è nel runtime, cioè nel motore che esegue il codice. Per questo un sito WordPress, Joomla o Drupal perfettamente aggiornato è vulnerabile lo stesso. Automattic, la società di WordPress.com, ha dichiarato che gli exploit funzionano su installazioni aggiornate di WordPress, Drupal e Joomla.
• mod_php è la configurazione più a rischio. Ma sono coinvolti anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. Se non sai cosa significano, è un motivo in più per continuare a leggere.
• Le versioni coinvolte risalgono fino alla 5.4. Chi ha un sito vecchio e mai toccato è nella casella peggiore.
• Dalla 8.1 in giù non esiste una release ufficiale di correzione. Esistono patch sul codice sorgente e backport (correzioni riportate su versioni vecchie) forniti da distributori come CloudLinux e Red Hat.

Chi aggiorna il PHP del tuo sito?

Questa è la domanda che dà il titolo all'articolo. La risposta dipende da dove vive il tuo sito.

Una nota sulle piattaforme che costruiscono siti senza codice: se hai scelto quella strada, l'ho detto in No-code: finalmente puoi costruire il tuo sito senza chiedere permesso a nessuno (ma fallo bene). La libertà di costruire è reale. La responsabilità di sapere chi tiene in piedi il motore, pure.

La trappola del numero di versione

Qui ho visto cadere persone molto competenti. Il numero di versione mente.

Quando un distributore come CloudLinux corregge una falla su una versione vecchia, spesso non cambia il numero principale. Il pacchetto ea-php84 patchato diventa 8.4.26-2, non 8.4.27. Se controlli solo il numero e pensi "26 è minore di 27, sono scoperto", sbagli. Se vedi "8.4" e pensi "tranquillo", sbagli nell'altro senso.

Cosa guardare davvero:

1. La data di compilazione del pacchetto. Deve essere il 21 ottobre 2026 o successiva.
2. Il changelog. Sui sistemi Red Hat e derivati si interroga con rpm -q --changelog <pacchetto>. Su Debian e Ubuntu con apt changelog. Deve citare le due vulnerabilità.
3. Il riavvio dei processi. Un pacchetto aggiornato su disco non protegge nulla se il processo che serve il sito è ancora quello vecchio, in memoria.
4. Il comando php -v non ti dice quello che pensi. Mostra la versione a riga di comando (CLI), che può essere diversa da quella che serve le pagine del tuo sito.
5. Tutte le versioni installate. Molti server ne hanno più di una. Se ne aggiorni una e dimentichi le altre, il sito che gira su quella dimenticata resta aperto. Vale anche per le versioni "alt-php" di CloudLinux.

Cinque domande da fare per iscritto

Se il tuo sito non è gestito da te, scrivi al tuo hosting. Non telefonare: l'email lascia traccia.

1. Quale versione di PHP sta servendo il mio dominio, oggi?
2. È stata applicata la correzione per CVE-2026-109618 e CVE-2026-109619? Con quale pacchetto e quale data?
3. I processi sono stati riavviati dopo l'aggiornamento?
4. Se uso una versione dalla 8.1 in giù, state usando un backport verificabile?
5. Avete controllato tracce di intrusione sul mio account?

Una risposta vaga è già una risposta. E se non sai chi risponderà, la risposta è: nessuno. È lo stesso problema che ho descritto in Il sito fatto vibe coding: la bomba a orologeria che Berto non vede: un sito che funziona non è un sito di cui qualcuno si sta occupando.

Aggiornare non è un clic

Questa è la sezione che i comunicati non scrivono, e quella in cui ho passato la parte più lunga di quei giorni.

Cambiare versione di PHP dal pannello dell'hosting richiede dieci secondi. Capire se il sito sopravvive richiede molto di più.

Deprecato non vuol dire rimosso

• Funzione deprecata: il linguaggio ti avvisa che un giorno non esisterà più. Il sito di solito funziona, ma i log si riempiono di avvertimenti.
• Funzione rimossa: non c'è più. Il sito smette di funzionare, a volte con una pagina bianca, a volte con un errore fatale.

Qualche esempio concreto, per capire di che epoca parliamo. Funzioni come create_function(), each() e __autoload() sono state rimosse con PHP 8.0. Le vecchie funzioni mysql_* per parlare con il database sono sparite già con PHP 7.0. Un tema scritto nel 2014 può contenerne ancora senza che nessuno se ne sia accorto, perché finora il vecchio PHP le tollerava.

Cosa mi è successo davvero

Nei nostri siti abbiamo dovuto modificare script che usavano espressioni deprecate. In altri casi si trattava di errori più gravi, sempre dovuti a espressioni obsolete, che rompevano il sito. Su alcuni è bastato correggere un paio di righe. Su altri l'intervento ha coinvolto più script e ha richiesto molto più lavoro.

Il caso peggiore non era un nostro sito. Era un vecchio sito, non realizzato da noi, fermo a una versione precedente di WordPress. L'abbiamo aggiornato all'ultima release e portato a una versione più recente di PHP, e si è rotto: incompatibilità in alcuni script di alcuni plugin del tema. Nessuno aveva toccato quel codice da anni.

Quella mattina, davanti allo schermo, non ho pensato "che bravo che sono stato a patchare". Ho pensato: ecco perché nessuno lo fa. Perché fare la cosa giusta costa, e se il sito si rompe il primo a rispondere sei tu.

Questa è la mia posizione, e non la ammorbidisco: non aggiornare per paura di rompere il sito è una scelta. Solo che il conto lo paga qualcun altro, e arriva dopo.

Il metodo, in breve

• Staging: una copia del sito su cui provare, mai direttamente la versione online.
• Salti a gradini: non passare dalla 7.4 alla 8.5 in un colpo solo. Si sale per versioni e si controllano i log a ogni passo.
• Strumenti di analisi del codice: PHPCompatibility, un controllo gratuito che si appoggia a PHP_CodeSniffer, segnala le incompatibilità prima che le scopra il visitatore.
• Un backup prima, sempre. Ne parlo per esteso in Il backup non è una precauzione: è la quarta parete del tuo sito, qui mi limito a ricordarlo.

La trappola dell'8.2

Se oggi sei sulla 8.2, sei in una finestra che si chiude: il supporto di sicurezza finisce il 31 dicembre 2026. Una patch di oggi su una versione che fra due mesi non riceve più correzioni è una tregua, non una soluzione. Dove possibile, la direzione giusta è la 8.4 o la 8.5.

Italia e Regno Unito: stessa raccomandazione, numeri non confrontabili

Sono tentato, ogni volta, di raccontarti la storia comoda: gli inglesi sono pragmatici e si muovono, gli italiani arrivano in ritardo. Sarebbe bello da scrivere. Ma i dati non la sostengono, e preferisco dirtelo.

Cosa dicono le due autorità, che guardano lo stesso problema da due parti diverse:

• NCSC (Regno Unito, 21 ottobre): censisci il PHP ovunque lo usi, aggiorna, valuta di mettere offline ciò che non puoi proteggere, cerca eventuali backdoor (accessi nascosti lasciati da un attaccante), usa il servizio Early Warning per ricevere segnalazioni. Chi tratta dati personali deve ricordare l'obbligo di sicurezza dell'articolo 32 del UK GDPR.
• CSIRT Italia (25 ottobre): stessa sostanza. Aggiorna, verifica, monitora.

Due autorità, un messaggio. I numeri che circolano, invece, non si possono mettere uno accanto all'altro: metodi di rilevazione diversi, date diverse, perimetri diversi. Quando senti dire che "l'Italia è messa peggio" o "il Regno Unito è messo meglio", chiedi sempre: misurato come, quando, su cosa?

Quello che posso dirti per esperienza diretta, vivendo tra Caserta e Londra, è un'altra cosa. A Shoreditch, quando una cosa del genere esce, le persone che ho intorno si aspettano un messaggio dal proprio fornitore. Nella mia esperienza, a Santa Maria Capua Vetere o a Portici molti titolari di sito aspettano che il problema si risolva da solo, perché nessuno ha mai detto loro che quel problema è loro. Prendi due casi tipo, inventati ma costruiti su cose che ho visto: Bobby, a Manchester, scrive una riga al suo fornitore: "Tutto a posto da voi?". Berto, a Caserta, non scrive a nessuno. Aspetta di vedere se telefono io.

Non è un dato. È un'impressione di chi lavora su entrambe le sponde, e va letta come tale. E la diagnosi è la stessa in entrambi i posti: il sito è di qualcuno, il PHP non è di nessuno.

Cosa è successo a chi ha fatto sul serio

Non ho esempi italiani da raccontarti, e non ne invento. Quello che si è visto in questi giorni, con fonti pubbliche:

Chi ha spento per precauzione

• cyber.gov.au, il sito dell'agenzia australiana di cybersicurezza, è andato offline la sera del 21 ottobre. Un portavoce del governo ha parlato di siti "temporaneamente non disponibili mentre si lavora per mitigare i rischi". Nessuno sfruttamento attivo noto al momento dell'allerta: spegnere era una scelta di prudenza, non una resa.
• Siti governativi in diversi Paesi europei (tra quelli citati dalla stampa: Francia, Finlandia, Danimarca, Paesi Bassi) sono stati messi offline in attesa della patch. Altre cronache citano il porto di Rotterdam. Nelle fonti che ho letto non emerge una compromissione confermata di questi soggetti.

Metterti offline per qualche ora con un sito che non guadagna: scomodo. Metterti offline con un sito che vende ogni minuto: costoso. Ma è una decisione, e qualcuno l'ha presa consapevolmente. È diverso dal non sapere.

Chi ha avvisato i clienti

Alcuni provider hanno pubblicato comunicazioni chiare: IONOS ha dichiarato che i siti ospitati sulla propria infrastruttura erano protetti, Automattic ha detto lo stesso per WordPress.com, Kinsta, Hostinger e altri hanno pubblicato guide per i clienti. Non tutte le comunicazioni sono ugualmente verificabili, e su nessun hosting italiano posso dirti nulla: non ho trovato dichiarazioni pubbliche che potessi controllare, e non scrivo ciò che non posso dimostrare.

Un'osservazione utile: una dichiarazione "i nostri server sono protetti" riguarda la loro infrastruttura. Non dice nulla sul tuo script obsoleto, né sul sito che gira su un'altra macchina.

La terza falla, con prudenza

Il 23 ottobre PHP ha segnalato CVE-2026-115560. Fai attenzione, perché le notizie l'hanno mescolata alle prime due, e non è la stessa cosa:

• Non è corretta dalle release del 21 ottobre.
• Richiede una combinazione insolita: un'applicazione che cambia il gestore delle sessioni a runtime con una certa impostazione, e il progresso di upload delle sessioni attivo.
• La mitigazione è disattivare session.upload_progress.enabled. Chi l'ha già fatto per CVE-2026-109619 non deve aggiungere altro.
• La correzione arriverà con la prossima release regolare. Al momento in cui scrivo non risultano sfruttamenti segnalati.

Se leggi questo articolo dopo qualche giorno, controlla lo stato aggiornato sul sito di PHP. Queste cose cambiano in fretta.

Cosa abbiamo fatto in Insight

Te lo racconto con onestà e con un limite: ti dico cosa abbiamo fatto, non come, perché i dettagli sono utili solo a chi vuole entrare.

Un contesto. In studio non abbiamo dipendenti. Abbiamo però un team di collaboratori esterni, ognuno con le proprie competenze, che ci aiutano in questi momenti. Compresi alcuni consulenti a Manchester. Alcune cose le facciamo da soli, altre non potremmo farle senza di loro.

Due velocità. Già da alcune settimane avevamo cominciato a lavorare sui nostri siti per rafforzare la sicurezza. L'uscita delle falle ci ha costretto a due cose diverse: dove eravamo già intervenuti, tornare ad aggiungere ulteriori elementi; dove non eravamo ancora intervenuti, farlo nel minor tempo possibile.

Sei cose concrete.

1. PHP alla 8.5 dove possibile. Dove i siti non lo permettevano, almeno la 8.2.
2. Riscrittura degli script con espressioni deprecate o obsolete, per renderli compatibili con la nuova release. Su alcuni siti è bastato poco. Su altri, molto.
3. Autenticazione a due fattori (2FA) sia sui pannelli di amministrazione degli hosting sia nei backend dei siti. Chi entra deve dimostrare di essere chi dice di essere con un secondo passaggio, oltre alla password.
4. Regole di sicurezza nel .htaccess, il file di configurazione del server per ogni sito, e un componente firewall dentro i siti.
5. Controlli di intrusione estesi a tutti i siti. Su molti li avevamo già fatti in modo approfondito. Li abbiamo estesi a quelli rimasti fuori.
6. Interventi anche per clienti senza contratto di assistenza attivo.

Una precisazione importante sui punti 3 e 4, perché è la più fraintesa. L'autenticazione a due fattori, le regole nel .htaccess e un firewall nel sito non fermano PHP2Shell. Chiudono altre porte, e sono porte da chiudere comunque. Ma la falla sta nel motore, non nell'accesso. Solo aggiornare il PHP la chiude. Lo dico perché ho visto più di un cliente rilassarsi dopo "abbiamo attivato la 2FA". No. Ottima cosa, e non basta.

Perché l'abbiamo fatto anche dove non c'era contratto

Uno dei clienti ha moltissimi siti e domini gestiti e ospitati da noi. Aveva subito un attacco ai suoi sistemi, che aveva coinvolto anche uno dei suoi siti: l'intervento su quei siti era cominciato qualche giorno prima di PHP2Shell. Quando sono usciti gli avvisi, non c'era un contratto di assistenza attivo. Siamo intervenuti lo stesso e lo abbiamo avvisato.

La ragione è semplice: gestiamo l'infrastruttura tecnica del sito, e quando succede una cosa del genere ci viene naturale agire nell'interesse del cliente, anche se non c'è un contratto. È un valore, non una strategia. Non sempre viene apprezzato. Troppo spesso non arriva nemmeno un grazie. Lo faccio comunque, e preferisco dirtelo senza risentimento: è il costo di fare questo mestiere come lo intendo.

Una cosa che ho imparato in quelle ore e che ti lascio: la comunicazione al cliente, nei primi momenti, conta quanto l'intervento. Quando non sai ancora tutto, ma sai già che ti riguarda, devi dirlo. Ho scritto come farlo in Le parole dell'emergenza: cosa scrivere ai clienti quando non sai ancora niente.

Checklist: cosa fare questa settimana

Dividila in due: cose che puoi fare tu in dieci minuti, cose che devi chiedere.

Da fare subito

 Scrivi su un foglio dove vivono tutti i tuoi siti, domini e sottodomini. Quello dimenticato è il primo a cadere.

 Identifica per ciascuno chi gestisce il server: provider, reseller, collaboratore, nessuno.

 Controlla nel pannello dell'hosting quale versione di PHP è impostata per ogni sito.

 Se puoi scegliere, passa a una versione supportata (8.4 o 8.5) dopo aver fatto un backup.

 Attiva la 2FA su pannello hosting e accesso amministrativo del sito.

 Cambia le password se non lo fai da mesi. Se hai dubbi sulle credenziali, leggi Come verificare se gli hacker hanno le nostre email e password.

Da chiedere (per iscritto)

 Le cinque domande di prima, al tuo provider o a chi gestisce il sito.

 Una conferma che ci sia stato un controllo di tracce di intrusione, non solo un aggiornamento.

Da pianificare

 Una copia di prova (staging) del sito prima di cambiare versione.

 Un controllo di compatibilità del codice dei plugin e del tema.

 Una data nel calendario per rivedere la situazione prima del 31 dicembre 2026 se sei sulla 8.2.

Cosa non fare

• Non aspettare che sia il tuo sito a rompersi per capire che il PHP non era aggiornato.
• Non fidarti del solo numero di versione. Data del pacchetto, changelog, riavvio.
• Non aggiornare in produzione senza copia di prova e senza backup. Mai.
• Non pensare che un plugin di sicurezza ti protegga da un problema nel motore. Non è il suo mestiere.
• Non pubblicare sui social "siamo al sicuro" se non hai verificato. Una frase detta troppo presto ha un costo se poi non è vera.
• Non ignorare la terza falla solo perché richiede condizioni insolite. Verifica l'impostazione e disattivala se non ti serve.

La mia posizione

Un sito non è un oggetto. È un servizio che qualcuno tiene acceso tutti i giorni, in silenzio, mentre tu pensi ad altro. Quando quel qualcuno non c'è, o non sai chi sia, il sito è come una casa con le chiavi sotto lo zerbino: finché nessuno passa, tutto bene.

PHP2Shell non è la prima falla e non sarà l'ultima. Ma è la prima di questa portata che ci mette davanti a una domanda semplice, che il mercato ha evitato per vent'anni perché la risposta è scomoda: a chi appartiene la manutenzione?

Se la risposta è "non lo so", hai il tuo lavoro di questa settimana.

Se vuoi una mano per capire dove sei, scrivimi. Ti dico dove guardare, e ti dico anche quando non serve preoccuparsi. Non vendo paura. Vendo lavoro fatto bene, che è meno spettacolare e più utile.