PHP2Shell è il nome dato a due vulnerabilità critiche nel linguaggio PHP: CVE-2026-109618 e CVE-2026-109619. In determinate condizioni, entrambe possono consentire a un aggressore di eseguire codice da remoto senza autenticarsi, mettendo a rischio i server interessati. PHP ha pubblicato le correzioni il 21 ottobre 2026; durante la risposta all’emergenza, alcune organizzazioni hanno sospeso o limitato temporaneamente i propri servizi. I tentativi di attacco osservati, però, non sono una prova di compromissione riuscita.
4
7
18
Che cosa fanno le vulnerabilità PHP2Shell
Le falle si trovano nel runtime di PHP, cioè nel componente che esegue il codice PHP sul server, non in uno specifico plugin o sito. Una riguarda la gestione degli errori di esaurimento della memoria; l’altra uno stato globale non più aggiornato. In determinate circostanze, una richiesta costruita ad hoc può portare all’esecuzione di codice da remoto. Una delle due vulnerabilità può inoltre esporre dati presenti nella memoria del processo.
4
11
PHP è molto diffuso: alcune stime indicano che venga utilizzato da una quota che arriva fino al 70% dei siti web. Questo dato non significa che tutti quei siti siano vulnerabili o altrettanto esposti. Il rischio effettivo dipende, tra l’altro, dalla versione in uso, dalla configurazione e dal fatto che il percorso di codice interessato sia raggiungibile.
45
46
Ricerca con AI e dettagli trapelati prima dell’annuncio
Le ricostruzioni dell’incidente attribuiscono attività di ricerca e segnalazione a team di Wiz, Calif e OpenAI; alcune coperture hanno descritto l’intelligenza artificiale come parte del lavoro. Le informazioni disponibili non confermano ogni dettaglio della scoperta, compresa una specifica sequenza da un exploit per WordPress a uno per Drupal o l’esatta ripartizione del lavoro su ciascuna CVE.
14
45
Secondo le ricostruzioni, un problema nella gestione della memoria era stato notato in precedenza, ma il suo potenziale di esecuzione di codice da remoto è stato dimostrato solo in seguito. La distinzione è importante: individuare un’anomalia non equivale a dimostrare che possa essere trasformata in un attacco pratico.
22
38
I dettagli sono trapelati prima della data prevista per la divulgazione pubblica, comprimendo i tempi della risposta e contribuendo alla corsa agli aggiornamenti.
6
23 Quando la comunicazione, la verifica delle patch e la loro installazione devono avvenire in tempi ridotti, una vulnerabilità diventa anche un problema operativo per chi gestisce i servizi.
Patch disponibili e limiti dei dati sugli attacchi
Gli aggiornamenti PHP correttivi pubblicati il 21 ottobre sono le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Gli amministratori dovrebbero consultare anche gli avvisi del proprio fornitore di sistema operativo o hosting: alcune distribuzioni forniscono la correzione tramite un aggiornamento retroportato, che potrebbe non riportare lo stesso numero di versione del rilascio PHP ufficiale.
4
39
Aziende di sicurezza hanno segnalato scansioni o tentativi di sfruttamento in concomitanza con la divulgazione. Resoconti relativi a Cloudflare hanno descritto un forte aumento dei tentativi osservati. Questi conteggi riguardano richieste o tentativi rilevati da specifici servizi e non indicano quante macchine siano state effettivamente violate.
5
36
Le valutazioni sulle compromissioni riuscite sono variate nel tempo. La BBC, al 22 ottobre, riferiva che non erano stati segnalati exploit riusciti; un aggiornamento di Beazley riportava tentativi su larga scala, ma non era a conoscenza di compromissioni di massa confermate. Anche Sansec ha rivisto la propria valutazione, giudicando meno probabile una diffusione di massa di quanto inizialmente previsto. Sono valutazioni legate al momento in cui sono state formulate: non rendono sicuro un server privo di patch.
7
9
18
Perché alcuni servizi sono andati offline
Alcune organizzazioni hanno disattivato o limitato temporaneamente i propri servizi per valutare l’esposizione e preparare gli aggiornamenti. Secondo le notizie disponibili, il governo britannico ha messo offline 32 servizi. Un servizio di monitoraggio dello stato dei siti ha registrato oltre 100 servizi con avvisi di interruzione, manutenzione o rischio legato a PHP2Shell prima che fosse disponibile una patch. Sono esempi dell’impatto operativo degli aggiornamenti d’emergenza, ma non dimostrano che quei servizi fossero stati attaccati.
22
34
Altre fonti hanno descritto risposte di governi e organizzazioni in diversi Paesi. Le informazioni disponibili, tuttavia, non permettono di stilare un elenco completo e verificato in modo indipendente di tutti i servizi interessati, né di confermare ogni singola interruzione citata.
20
25
Cosa dovrebbero fare i gestori dei siti
- Individuare tutte le installazioni PHP. Controllare server di produzione, container, sistemi secondari e ambienti di hosting gestito: non basta verificare il sito principale.
- Installare la correzione appropriata. Applicare una versione corretta o un aggiornamento retroportato confermato dal fornitore. Riavviare i processi o i servizi PHP quando necessario e verificare quale versione è effettivamente in esecuzione. Aggiornare applicazioni o plugin non sostituisce la correzione del runtime PHP.
14
39
- Ridurre l’esposizione se non è possibile aggiornare subito. In base al rischio e all’impatto sul servizio, valutare di limitare l’accesso pubblico o disattivarlo temporaneamente. Le regole di rete possono aiutare nell’immediato, ma non sostituiscono l’installazione della patch.
- Controllare eventuali segnali di intrusione. Esaminare i log pertinenti e cercare file, processi o account amministrativi inattesi. Se si sospetta una compromissione, conservare le evidenze e avviare un’indagine: applicare la patch non rimuove un’eventuale intrusione già avvenuta.
- Chiedere conferma ai fornitori. Le organizzazioni che si affidano a un servizio di hosting o a un provider gestito dovrebbero ottenere conferma esplicita che tutte le istanze PHP da cui dipendono siano state corrette.
La NSA ha raccomandato di applicare le patch critiche e ha dichiarato di dare priorità all’individuazione di attori malevoli che potrebbero tentare di sfruttare PHP2Shell. Anche l’FBI ha invitato le organizzazioni ad aggiornare le installazioni PHP. Le fonti disponibili non documentano un unico ordine congiunto di FBI, NSA e CISA che imponesse a tutte le organizzazioni di spegnere i sistemi impossibilitate ad aggiornarli.
17
28
Cosa possono fare gli utenti
Tenere aggiornati dispositivi, applicazioni e router, attivare l’autenticazione a più fattori e usare password uniche sono buone pratiche di sicurezza generale. Non correggono però il PHP installato sul server di un sito: quell’intervento spetta a chi lo gestisce o al suo provider di hosting.
La lezione pratica di PHP2Shell è la necessità di aggiornare in modo rapido e verificabile, preparandosi a finestre di risposta più brevi. L’incidente giustifica l’attenzione alla rapidità con cui ricerca e tentativi di sfruttamento possono evolvere. Non giustifica invece l’equivalenza tra tentativi osservati e compromissioni di massa confermate, né l’idea di un collasso generale della sicurezza del web.