Due vulnerabilità critiche di PHP hanno spinto enti e aziende a sospendere servizi online per aggiornarli. Al 28 ottobre emergono tentativi di attacco, una terza falla più circoscritta e i primi dati sui siti della pubblica amministrazione italiana.
PHP2Shell è il nome dato a due vulnerabilità critiche del motore PHP, usato da molti siti per creare le pagine che vediamo nel browser. Il 21 ottobre 2026, diverse amministrazioni e aziende hanno spento temporaneamente alcuni servizi per installare gli aggiornamenti. La sospensione ha impedito l’accesso ai cittadini, ma non prova che quei siti abbiano subito una violazione. Reuters ha raccolto i casi segnalati in vari Paesi. www.reuters.com
Una settimana dopo, il quadro è più chiaro. Le correzioni per le due falle principali sono disponibili. I ricercatori hanno osservato tentativi di sfruttamento, anche prima dell’annuncio pubblico. In Italia, una verifica preliminare mostra che una parte degli indirizzi della pubblica amministrazione ha iniziato a dichiarare versioni aggiornate di PHP. È emersa anche una terza vulnerabilità, che richiede condizioni particolari e attende una correzione ordinaria. www.php.net
Che cos’è PHP2Shell e perché riguarda tanti siti
PHP lavora sul server: elabora le richieste e prepara le pagine inviate ai visitatori. È alla base di molti siti realizzati con WordPress e di altre applicazioni web. PHP2Shell riguarda il funzionamento interno di PHP, non una singola pagina, un tema o un plugin. Per questo un normale aggiornamento del solo CMS non basta a eliminare le due falle. blog.cloudflare.com
Le vulnerabilità hanno i codici CVE-2026-109618 e CVE-2026-109619. Entrambe hanno ricevuto un punteggio di gravità 9,2 su 10. In determinate condizioni, un aggressore potrebbe inviare richieste web preparate appositamente ed eseguire codice sul server senza autenticarsi. La prima falla coinvolge la gestione della memoria quando PHP la esaurisce. La seconda riguarda informazioni interne che possono restare accessibili dopo un errore fatale. L’avviso del progetto PHP e l’analisi di CERT-EU spiegano i due problemi.
Il rischio non è identico per ogni configurazione. PHP indica come particolarmente esposti i server che usano mod_php, perché è stato dimostrato un percorso d’attacco prima dell’esecuzione del codice dell’applicazione. Anche gli altri modi di eseguire PHP richiedono comunque una verifica e l’aggiornamento.
Perché i siti pubblici sono stati sospesi
Il 21 ottobre, enti in Germania, Francia, Paesi Bassi e Finlandia hanno sospeso alcuni siti o servizi. Si sono registrate interruzioni anche in altri Paesi. Nei Paesi Bassi, per esempio, Reuters ha citato il portale governativo Overheid.nl, il porto di Rotterdam e siti ospedalieri. La Finlandia ha precisato che la propria sospensione era precauzionale e che non aveva rilevato una violazione dei dati. www.reuters.com
La scelta di fermare un servizio ha un costo: per alcune ore, una persona può non riuscire a consultare una pagina o completare una pratica. Tuttavia, se un gestore non può installare subito la correzione, limitare l’accesso dall’esterno riduce l’esposizione durante l’emergenza. CERT-EU raccomanda di isolare le applicazioni esposte quando l’aggiornamento immediato non è possibile. cert.europa.eu
Questo non significa che tutti i siti sospesi fossero già stati attaccati. Le organizzazioni possono intervenire prima di trovare una compromissione, proprio per prevenirla.
I tentativi di attacco sono iniziati prima delle patch
La prudenza aveva una ragione concreta. Amazon Threat Intelligence riferisce di aver individuato un tentativo contro un proprio sistema di rilevamento il 17 ottobre, quattro giorni prima della divulgazione delle falle. Altri tentativi sono comparsi il 21 ottobre, nelle ore precedenti e successive al rilascio degli aggiornamenti. aws.amazon.com
Amazon precisa un limite: non sa se i primi tentativi osservati contro i suoi sistemi di prova avrebbero funzionato su siti reali. Anche Cloudflare ha rilevato traffico d’attacco e ha distribuito regole per il proprio firewall web. La società descrive le protezioni adottate, ma raccomanda comunque di aggiornare PHP. aws.amazon.com
Un tentativo registrato non equivale a una compromissione riuscita. Per stabilire se un sito sia stato violato occorrono verifiche sui registri e sui sistemi interessati. Il numero di richieste malevole bloccate, da solo, non dice quanti server siano stati compromessi.
PHP2Shell in Italia: cosa mostrano i controlli sui siti della PA
Il CERT-AGID ha avviato una ricognizione sugli indirizzi presenti nell’Indice delle Pubbliche Amministrazioni. Nella prima verifica ha trovato 650 URL che dichiaravano una versione PHP potenzialmente vulnerabile. Si trattava del 3,2% degli indirizzi raggiungibili esaminati. L’ente ha avvisato le amministrazioni interessate perché controllassero i sistemi effettivi.
Il controllo ripetuto il 26 ottobre ha rilevato un cambiamento. Tra le 650 URL inizialmente segnalate, 168 dichiaravano una versione aggiornata e 453 continuavano a dichiarare una versione potenzialmente vulnerabile. Altre 17 non mostravano più una versione PHP rilevabile e 12 non hanno risposto entro il tempo previsto dalla verifica. cert-agid.gov.it
Questi numeri descrivono indirizzi web, non amministrazioni violate. Il CERT-AGID ha letto le informazioni comunicate dai server senza tentare attacchi. Una versione esposta nell’intestazione di una risposta può non mostrare una correzione già integrata dal fornitore. Inoltre, nascondere la versione non sostituisce l’aggiornamento. Servono controlli diretti sui sistemi per confermare lo stato di ciascun servizio.
La terza vulnerabilità è già stata corretta?
Il 23 ottobre, il team PHP ha segnalato CVE-2026-115560, una terza possibile via di esecuzione remota. Perché si presenti, l’applicazione deve usare una combinazione insolita di configurazioni e modificare durante l’esecuzione il gestore delle sessioni. Deve essere attiva anche la funzione che segue l’avanzamento degli upload. Il progetto PHP considera poco probabile questa combinazione e prevede una correzione nel prossimo rilascio ordinario.
Le patch del 21 ottobre non correggono questa terza falla. In attesa della nuova versione, PHP suggerisce di impostare session.upload_progress.enabled=0 nella configurazione effettiva. Occorre poi riavviare i processi interessati e verificare se l’applicazione dipende dalla funzione disabilitata. CERT-AGID ha chiarito la portata della misura. Al 28 ottobre, nelle comunicazioni ufficiali consultate, non compare ancora una patch dedicata.
Cosa deve verificare chi gestisce un sito WordPress
Il primo controllo riguarda la versione PHP realmente in esecuzione. Chi usa un hosting gestito può chiedere al fornitore se ha installato PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure un pacchetto della propria distribuzione con le correzioni integrate. Le versioni più vecchie possono richiedere interventi specifici del fornitore o una migrazione.
Il secondo controllo riguarda i servizi che espongono PHP: sito principale, sottodomini, aree riservate e applicazioni accessorie. Un firewall web può bloccare percorsi d’attacco conosciuti, ma non sostituisce la patch per le prime due falle. Per la terza, l’amministratore deve valutare la configurazione delle sessioni e la misura temporanea indicata da PHP. blog.cloudflare.com
Per i lettori, PHP2Shell mostra perché un sito può andare offline anche senza aver subito un attacco riuscito. Per chi lo gestisce, la priorità è verificare le correzioni applicate e distinguere una protezione provvisoria da un aggiornamento definitivo. I prossimi dati sulle verifiche italiane aiuteranno a capire quanto rapidamente i servizi esposti avranno completato il lavoro.