Il 21 ottobre 2026 il mondo della sicurezza informatica ha vissuto una di quelle giornate in cui gli amministratori di sistema sono diventano improvvisamente intrattabili e scorbutici, con tic nervosi persistenti e, in alcuni casi, sguardo perso nel vuoto.
La causa, questa volta, non è il solito utente con la domanda cretina ma èPHP, uno dei linguaggi di programmazione più utilizzati per realizzare siti e applicazioni web. Due vulnerabilità critiche, battezzate collettivamentePHP2Shell, hanno messo potenzialmente a rischio milioni di server in tutto il mondo.
Fin qui, purtroppo, niente di particolarmente insolito: le vulnerabilità vengono scoperte continuamente, anche nei software più diffusi.
Questa volta, però, ci sono almeno tre elementi che rendono la vicenda particolarmente preoccupante.
Il primo è che entrambe le falle permettono, in determinate condizioni, di eseguire codice direttamente sul server senza bisogno di autenticarsi.
Il secondo è che il problema non riguarda una particolare applicazione, un plugin scritto male o un sito configurato in maniera approssimativa:si trova nel motore PHP stesso.
Il terzo, probabilmente il più inquietante, è che alcune informazioni sulle vulnerabilità sono diventate pubbliche prima della distribuzione delle patch. E, come vedremo, qualcuno aveva già iniziato a tentare di sfruttarle.
Prima di tutto: quanto è grave?
Le vulnerabilità sono identificate come:
- CVE-2026-109618– Corruzione della memoria durante la gestione di errori di esaurimento della memoria disponibile.
- CVE-2026-109619– Utilizzo di riferimenti a memoria già liberata, rimasti nello stato interno di PHP.
Entrambe hanno ricevuto un punteggioCVSS4.0 di 9,2 su 10, classificandosi come critiche.
Quel numero non promette nulla di buono.
L'unica cosa positiva è che non è 10, come riportato inizialmente da alcune indiscrezioni, perché lo sfruttamento richiede condizioni tecniche particolari e presenta una certa complessità.
Ma il risultato potenziale resta estremamente serio: un attaccante remoto, senza conoscere password e senza possedere un account, può arrivare a eseguire codice sul server vulnerabile.
In gergo si parla diRCE, Remote Code Execution.
Questo non significa necessariamente ottenere immediatamente i privilegi di amministratore dell'intero sistema. Il codice viene comunque eseguito con i permessi del processo PHP compromesso.
Sono però privilegi che, in molti ambienti, permettono di accedere ai file dell'applicazione, leggere configurazioni, recuperare credenziali dei database, modificare contenuti e potenzialmente utilizzare il server come punto di partenza per ulteriori attacchi.
Non esattamente qualcosa da prendere alla leggera.
Perché PHP2Shell è così pericoloso?
Per capire il problema bisogna ricordare (o capire, per alcuni) come funziona un sito web dinamico.
Quando visitiamo un sito realizzato con WordPress, per esempio, il browser invia una richiesta al server. PHP interviene per eseguire il codice necessario, interrogare eventualmente un database e preparare la risposta.
Normalmente, quando viene scoperta una vulnerabilità in un plugin WordPress, il problema riguarda quel particolare componente. Chi non lo utilizza non è interessato.
Con PHP2Shell la situazione è diversa.
L'interprete PHP lavora ad un livello inferiore rispetto al motore WordPress. E in questo caso "inferiore" = "no buono".
Il problema riguarda il software che esegue le applicazioni, non le applicazioni stesse.
Un sito WordPress perfettamente aggiornato, con plugin sicuri e un codice sviluppato rispettando tutte le buone pratiche, può comunque essere vulnerabile se il server utilizza una versione di PHP non corretta.
Lo stesso principio vale per Drupal, Joomla, Magento e numerose altre piattaforme.
Ancora peggio: per almeno uno degli scenari dimostrati, su server Apache configurati con mod_php, l'attacco può avvenire durante l'elaborazione della richiesta HTTP,prima ancora che venga eseguita una singola istruzione del codice dell'applicazione.
In pratica, il sito non ha nemmeno il tempo di difendersi.
Che cosa succede tecnicamente?
Cerchiamo di spiegarlo senza trasformare l'articolo in un corso di gestione della memoria.
PHP, come qualunque software, deve allocare e liberare memoria mentre lavora.
Quando una richiesta consuma troppa memoria, il linguaggio dispone di meccanismi per interrompere l'operazione ed evitare che il processo continui a consumare risorse fino a farmorirebloccare il server.
Il problema nasce quando questa interruzione avviene in un momento particolarmente delicato.
La prima vulnerabilità: quando la memoria finisce nel momento sbagliato
La CVE-2026-109618 riguarda la gestione degli erroriOut Of Memory, cioè l'esaurimento della memoria disponibile per una determinata operazione.
In alcune circostanze PHP può interrompere l'elaborazione mentre alcune strutture interne non sono ancora state inizializzate completamente.
Successivamente, durante le operazioni di pulizia, il programma può tentare di utilizzare quelle strutture come se fossero valide. Il risultato è una possibile corruzione della memoria.
I ricercatori hanno dimostrato che richieste HTTP costruite appositamente, anche sfruttando particolari caratteristiche della gestione degli upload, possono provocare queste condizioni.
Con una sequenza di operazioni sufficientemente precisa, la corruzione può diventare un mezzo per eseguire codice arbitrario.
La seconda vulnerabilità: usare memoria che non esiste più
La CVE-2026-109619 sfrutta invece un problema comunemente chiamatoUse After Free.
Immaginiamo che PHP utilizzi una porzione di memoria per conservare alcune informazioni durante una richiesta.
Terminata l'operazione, quella memoria viene liberata e resa disponibile per altri utilizzi.
Il problema nasce quando un riferimento a quella memoria rimane attivo anche dopo la sua liberazione. In pratica, PHP non ha cancellato bene tutto e qualcosa è rimasto lì.
Una richiesta successiva, gestita dallo stesso processo, potrebbe quindi utilizzare dati ancora presenti ma non più validi.
Se un attaccante riesce a controllare opportunamente la disposizione dei dati in memoria, questa condizione può essere sfruttata per ottenere l'esecuzione di codice.
È una semplificazione, naturalmente, non è così semplice come dirlo (ed ecco il 9.2 invece del 10) ma rende l'idea.
Ed in questo caso non si sta parlando di password deboli o server configuratida schifomale, stiamo parlando di errori nella gestione interna della memoria di un componente che gestisce milioni di siti in tutto il mondo.
Il vero pasticcio: le informazioni diffuse prima delle patch
Ed eccoci al titolo, le informazioni diffuse troppo presto.
Le vulnerabilità erano state individuate attraverso attività di ricerca sulla sicurezza e segnalate ai responsabili di PHP.
Era stato quindi organizzato un processo diCoordinated Vulnerability Disclosure, ovvero divulgazione coordinata delle vulnerabilità.
Il principio è abbastanza semplice: chi scopre una falla critica informa riservatamente gli sviluppatori, concede loro il tempo necessario per preparare una correzione e concorda una data per rendere pubblici i dettagli.
In questo modo, quando gli attaccanti vengono a conoscenza del problema, gli amministratori hanno già la possibilità di installare una patch.
È un equilibrio delicato, ma fondamentale.
Il 20 ottobre, però, alcune informazioni relative alle due vulnerabilità hanno iniziato a circolare pubblicamente.
Su Hacker News è comparso un messaggio che anticipava l'esistenza delle falle e annunciava una divulgazione imminente. Il messaggio è stato rimosso, ma gli screenshot hanno continuato a diffondersi.
Tra il materiale circolato comparivano anche riferimenti a uno strumento di exploit chiamato PHP2Shell.
Secondo la ricostruzione pubblicata successivamente, nella stessa serata è stato inoltre reso accessibile per errore un video dimostrativo relativo a una proof of concept.
È importante precisare chenon tutto il materiale diffuso in quella fase costituiva un exploit completo e funzionante, ma le informazioni erano sufficientemente concrete da costringere il team PHP ad anticipare le comunicazioni e accelerare il rilascio delle patch.
La pubblicazione delle correzioni è stata quindi anticipata al 21 ottobre.
Ma che differenza c'è tra una PoC e un exploit?
UnaProof of Concept, abbreviata PoC, è una dimostrazione tecnica che serve a provare l'esistenza e la possibile sfruttabilità di una vulnerabilità.
Non necessariamente è uno strumento pronto per attaccare indiscriminatamente migliaia di server.
Un exploit operativo, invece, è codice che permette di sfruttare concretamente una falla nelle condizioni per cui è stato sviluppato.
La distinzione è importante, ma non deve farci sottovalutare una PoC.
Per un ricercatore esperto, una dimostrazione sufficientemente dettagliata può costituire il punto di partenza per sviluppare un attacco completo.
E oggi, anche grazie agli strumenti di analisi automatizzata e all'intelligenza artificiale, il tempo necessario per passare dalla conoscenza di una vulnerabilità alla costruzione di un exploit può essere molto ridotto.
Il problema, quindi, non è semplicemente che qualcuno abbia parlato pubblicamente di PHP2Shell, quanto cheinformazioni utili agli attaccanti sono circolate quando buona parte dei sistemi interessati non aveva ancora una correzione disponibile.
Questa è la situazione che, in ambito cybersecurity,fa recitare rosari interi ai sistemistisi cerca normalmente di evitare.
Gli attacchi erano già cominciati il 17 ottobre
C'è un altro elemento emerso successivamente che rende la vicenda ancora più "interessante", degna di ... no, non lo dico e decisamente meno rassicurante.
Amazon Threat Intelligence ha comunicato di aver individuato, attraverso la propria infrastruttura di honeypot MadPot, un tentativo di sfruttamento di PHP2Shell risalente addirittura al17 ottobre 2026.
Quattro giorni prima della divulgazione ufficiale e tre giorni prima delle indiscrezioni circolate pubblicamente.
Un honeypot è un sistema progettato per attirare e registrare attività ostili, permettendo ai ricercatori di studiare tecniche e strumenti utilizzati dagli attaccanti.
Amazon ha rilevato che il tentativo proveniva da un indirizzo IP associato a un servizio commerciale di anonimizzazione.
Questo elemento suggerisce un'attività intenzionale, ma non permette di stabilire chi fosse l'autore né come avesse ottenuto le informazioni sulla vulnerabilità.
Non è nemmeno possibile affermare, sulla base di quella rilevazione, che un server reale sia stato effettivamente compromesso.
Resta però un fatto: qualcuno stava già provando a sfruttare il problema prima che diventasse pubblico.
Il 21 ottobre Amazon ha individuato ulteriori tentativi provenienti da infrastrutture differenti, mentre dopo la pubblicazione delle patch sono comparsi rapidamente nuovi exploit dimostrativi.
La stessa Amazon ha descritto PHP2Shell come una vulnerabilità ormai oggetto di diffusi tentativi di sfruttamento.
La distinzione è fondamentale:abbiamo conferme di attività di attacco, non necessariamente di compromissioni riuscite su larga scala.
Ma è già abbastanza per giustificare la massima attenzione.
Siti governativi oscurati: che cosa è successo?
La gravità della situazione ha spinto numerose organizzazioni a prendere una decisione drastica:chiudere le stallerendere temporaneamente indisponibili i propri siti.
Nei Paesi Bassi sono stati segnalati disservizi riguardanti DigiD, il sistema di identificazione digitale utilizzato per accedere ai servizi pubblici (come il nostro SPID), oltre ad altri portali istituzionali.
Anche organizzazioni e amministrazioni in altri Paesi europei hanno temporaneamente disattivato servizi esposti a Internet.
L'Università di Friburgo, in Germania, ha sospeso l'accesso a diversi servizi web, compresi sistemi universitari e piattaforme interne.
Attenzione: non significa che tutti questi siti siano stati violati.
In molti casi si è trattato diinterruzioni preventive, decise per evitare di lasciare online sistemi potenzialmente vulnerabili in attesa degli aggiornamenti.
Una scelta pesante, che nessun sistemista (a parte chi gestisce un sito personale o amatoriale) prenderebbe alla leggera e ancora di più per i servizi pubblici, ma comprensibile quando l'alternativa è esporsi a un possibile accesso non autorizzato.
Meglio un sito temporaneamente irraggiungibile che un server compromesso, con tutte le conseguenze che questo potrebbe comportare, le tonnellate di dati che finiscono chissà dove oltre alle centinaia di comunicazioni e rotture di scatole che ne conseguirebbero.
Facciamo prima: spegniamo tutto finchè funziona e vediamo che fare.
Le patch ci sono. Quali versioni bisogna installare?
Il team PHP ha pubblicato il 21 ottobre quattro aggiornamenti di sicurezza (e, da cosa ho visto, posso confermare che provider come Aruba mettono a disposizione dei siti in hosting versioni già aggiornate).
| Ramo PHP | Versione corretta |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Le installazioni precedenti a queste versioni, nei rispettivi rami, sono vulnerabili se non hanno ricevuto correzioni equivalenti distribuite dal proprio fornitore.
La situazione è particolarmente delicata per chi utilizza PHP 8.1 o versioni ancora più vecchie, ormai fuori dal normale ciclo di supporto del progetto.
Alcuni distributori Linux possono fornire correzioni tramitebackport, mantenendo apparentemente invariato il numero di versione principale.
Per questo motivo, sui sistemi gestiti attraverso pacchetti della distribuzione, è necessario verificare anche gli avvisi di sicurezza e i changelog del fornitore.
Va inoltre ricordato che PHP 8.2 terminerà il supporto di sicurezza ufficiale il 31 dicembre 2026.
Chi lo utilizza dovrebbesvegliarsi e capire che siamo nel 2026pianificare il passaggio a una versione più recente, oltre a installare immediatamente la correzione.
E chi ha un sito WordPress?
Qui arriviamo a una questione che riguarda direttamente moltissimi proprietari di siti, compreso chi gestisce un semplice blog personale.
Aggiornare WordPress non risolve PHP2Shell.
Non serve nemmeno aggiornare tutti i plugin, cambiare tema o reinstallare ilCMS.
Sono operazioni normalmente utili per la sicurezza, giusto farle periodicamente, ma non correggono queste due vulnerabilità.
Il componente interessato è PHP, installato e gestito a livello di server.
Chi utilizza un hosting condiviso deve quindi verificare quale versione di PHP sia effettivamente in esecuzione e se il provider abbia distribuito gli aggiornamenti (Ripeto: Aruba permette di selezionare la versione 8.5.12 che dovrebbe essere fixata).
In WordPress è possibile consultare le informazioni sull'ambiente server attraverso la sezioneStrumenti → Salute del sito → Informazioni → Server.
Questa verifica permette di conoscere la versione PHP utilizzata dal sito, ma attenzione: il numero di versione, da solo, non è sempre sufficiente per accertare la presenza di una patch distribuita tramite backport.
In caso di dubbio, la soluzione migliore è contattare il provider (buona fortuna, con alcuni di loro) e chiedere esplicitamente se siano state applicate le correzioni per CVE-2026-109618 e CVE-2026-109619.
Per chi amministra direttamente il server, oltre all'aggiornamento è necessario assicurarsi che i processi PHP vengano riavviati, in modo che non continuino a utilizzare il vecchio codice.
Un firewall può proteggerci?
In parte.
Cloudflare, per esempio, ha sviluppato e distribuito regole di protezione attraverso il proprio Web Application Firewall.
Queste misure possono intercettare e bloccare alcune richieste costruite per sfruttare le vulnerabilità.
Sono strumenti importanti, soprattutto nelle ore che precedono la disponibilità delle patch.
Ma non equivalgono a una correzione del problema.
Il team PHP ha chiarito che non esistono mitigazioni complete alternative all'aggiornamento.
Disabilitare determinate funzionalità, limitare le richieste HTTP o utilizzare un WAF può ridurre l'esposizione, ma non garantisce che tutte le possibili modalità di attacco vengano bloccate.
La soluzione definitiva è correggere PHP.
E, considerando le attività ostili già osservate, per i server esposti è opportuno verificare anche i log e gli eventuali segnali di compromissione, non limitarsi a installare la patch e considerare automaticamente chiuso l'incidente.
Una lezione che va oltre PHP
La vicenda PHP2Shell evidenzia almeno due problemi strutturali della sicurezza informatica moderna.
Il primo è la dipendenza da componenti software estremamente diffusi.
PHP è un componente direi quasi fondamentale, alla base di una parte enorme del web.
Una vulnerabilità nel suo motore può coinvolgere contemporaneamente applicazioni diversissime, indipendentemente dalla qualità del codice sviluppato da chi le utilizza.
Il secondo è il tempo sempre più ridotto che separa la scoperta di una vulnerabilità dal suo sfruttamento, come su queste pagine dico da mesi ormai.
La divulgazione coordinata rimane uno strumento fondamentale, ma funziona soltanto se le informazioni sensibili vengono gestite correttamente e se le patch possono raggiungere rapidamente gli amministratori.
In questo caso la diffusione anticipata di informazioni ha complicato ulteriormente una situazione già delicata.
E la rilevazione di Amazon del 17 ottobre dimostra che non possiamo nemmeno presumere che gli attacchi inizino soltanto dopo la pubblicazione di un advisory.
Una vulnerabilità può essere scoperta indipendentemente da più soggetti
E non è detto che siano tutti dalla stessa parte della barricata.
Qualcuno potrebbe tentare di sfruttarla senza dire niente a nessuno, mentre gli sviluppatori stanno ancora lavorando alla correzione o addirittura nemmeno sanno che esiste.
In definitiva
PHP2Shell non è la solita notizia allarmistica, solitamente infondata, secondo cui Internet starebbe per collassare da un momento all'altro.
È un incidente di sicurezza estremamente serio e da prendere con la massima considerazione.
Due vulnerabilità critiche, presenti in un componente diffusissimo, hanno reso possibile l'esecuzione remota di codice senza autenticazione. Le informazioni sono circolate prima del rilascio delle patch e sono stati rilevati tentativi di sfruttamento addirittura precedenti alla divulgazione pubblica.
Non è la fine del mondo, però ... come direbbe il buon Giacobazzi "quando succede, un po' balli!"
Le correzioni sono disponibili e devono essere applicate con urgenza.
Ma questa vicenda dovrebbe ricordarci soprattutto una cosa:la sicurezza di un sito non dipende soltanto dal codice che vediamo o dai plugin che installiamo, ma anche da tutti i componenti software sui quali quel sito si appoggia.
E quando una falla viene scoperta in uno di questi componenti, il problema può riguardare contemporaneamente milioni di sistemi.
Questa volta il mondo PHP ha avuto un bel problema da gestire.
E il fatto che qualcuno abbia iniziato a bussare alla porta prima ancora che fosse possibile cambiarne la serratura è probabilmente l'aspetto più preoccupante di tutta la storia.
Fonti e approfondimenti
- PHP.net – Security advisory e aggiornamenti del 21 ottobre 2026
- GitHub PHP – Advisory CVE-2026-109618
- GitHub PHP – Advisory CVE-2026-109619
- Amazon Threat Intelligence – Tentativi di sfruttamento prima della divulgazione
- Cloudflare – Protezioni contro PHP2Shell
- NCSC Netherlands – Informazioni operative su PHP2Shell
- Ubuntu – Aggiornamenti di sicurezza PHP2Shell
- Check Point – Analisi della fuga di informazioni