PHP2Shell, 22,6 milioni di istanze esposte: CERT-AGID pubblica i test

🛡️ Executive Summary

• Palo Alto Networks individua oltre 22,6 milioni di istanze PHP potenzialmente vulnerabili a PHP2Shell, mentre Cloudflare segnala tentativi di sfruttamento nell’ordine dei milioni.
• Il CERT-AGID pubblica due strumenti per verificare l’esposizione: OpenAI PHP2Shell Checker analizza le versioni, mentre Assetnote PHP2Shell Scanner effettua test HTTP attivi che possono interferire con i servizi.
• Le patch PHP sono disponibili, ma anche PAN-OS e Panorama risultano interessati. Palo Alto Networks annuncia correzioni per i firewall e raccomanda di limitare l’accesso alle interfacce amministrative.

PHP2Shell è ormai un problema di sicurezza di portata globale, con milioni di istanze potenzialmente vulnerabili e un’attività offensiva cresciuta rapidamente dopo la divulgazione delle falle. Palo Alto Networks ha individuato oltre 22,6 milioni di esposizioni potenziali attraverso la propria telemetria, mentre Cloudflare ha segnalato milioni di tentativi di sfruttamento delle vulnerabilità CVE-2026-109618 e CVE-2026-109619. In Italia, il CERT-AGID ha pubblicato indicazioni operative e due strumenti open source per verificare i sistemi interessati, distinguendo il controllo passivo della versione PHP dalle verifiche attive attraverso richieste HTTP. L’emergenza riguarda il motore PHP utilizzato da applicazioni web, CMS e servizi aziendali, ma si estende anche a prodotti di sicurezza che incorporano componenti vulnerabili. La priorità non è più attendere le patch, disponibili dal 21 ottobre, ma dimostrare che siano state applicate ai servizi effettivamente raggiungibili da Internet.

Palo Alto Networks rileva 22,6 milioni di istanze PHP potenzialmente vulnerabili

La dimensione dell’esposizione emerge dalla ricerca di Palo Alto Networks Unit 42, che attraverso Cortex Xpanse ha identificato oltre 22,6 milioni di istanze pubblicamente esposte e potenzialmente vulnerabili alle due falle PHP2Shell. Il dato, riportato nel Threat Brief ufficiale sulle CVE-2026-109618 e CVE-2026-109619, supera nettamente le esposizioni osservate per numerose vulnerabilità di appliance enterprise. La società confronta questa superficie con circa 50.000 istanze NetScaler e 16.000 sistemi BeyondTrust potenzialmente interessati da precedenti problemi di sicurezza, evidenziando quanto la diffusione di una libreria o di un runtime open source possa amplificare l’impatto di una singola vulnerabilità. Il numero non corrisponde a 22,6 milioni di server compromessi, né dimostra che ogni istanza sia realmente sfruttabile: rappresenta il perimetro potenziale individuato dalla piattaforma di esposizione, che richiede verifiche ulteriori su versioni, configurazioni e correzioni già distribuite.

Il rischio tecnico riguarda due errori nella gestione della memoria dell’interprete. CVE-2026-109618 interessa il recupero dagli errori Out of Memory e può lasciare strutture interne in uno stato incoerente, mentre CVE-2026-109619 permette di riutilizzare riferimenti a memoria già liberata tra richieste successive. Entrambe sono classificate CVSS 4.0 9,2 e possono consentire esecuzione remota di codice senza autenticazione. Le correzioni sono disponibili nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, come già documentato nell’approfondimento sulle patch PHP2Shell e sui rischi per WordPress e gli altri CMS.

Leggi anche: PHP2Shell attaccato prima delle patch, GitLab corregge una RCE CVSS 10

Cloudflare e Imperva misurano l’accelerazione degli attacchi contro PHP2Shell

La pubblicazione delle patch è stata accompagnata da un’accelerazione delle attività offensive. Secondo le comunicazioni del CEO di Cloudflare Matthew Prince, la rete dell’azienda ha osservato migliaia di tentativi nelle dieci ore precedenti alla divulgazione, decine di migliaia entro i primi 45 minuti e centinaia di migliaia nelle due ore successive, fino a raggiungere milioni di tentativi. Una misurazione indipendente arriva da Imperva Threat Research, che nelle prime 24 ore ha registrato 482.342 richieste, 122.311 sessioni di attacco, 21.998 siti presi di mira e attività distribuite in 103 Paesi. Il comportamento appare prevalentemente automatizzato, con una media di circa quattro richieste per sessione, coerente con campagne che cercano rapidamente server vulnerabili senza sviluppare necessariamente un attacco approfondito contro ogni bersaglio.

Le rilevazioni devono essere interpretate distinguendo scansioni, tentativi di exploit e compromissioni riuscite. La presenza di traffico ostile non dimostra che gli attaccanti abbiano ottenuto l’esecuzione di codice sui server presi di mira. Amazon Threat Intelligence aveva già documentato un tentativo di sfruttamento il 17 ottobre, quattro giorni prima della pubblicazione ufficiale, attraverso la propria rete di honeypot MadPot. Questo dato rende necessario analizzare anche gli eventi anteriori al 21 ottobre, senza considerare la data di rilascio delle patch come l’inizio dell’attività criminale. La capacità degli aggressori di automatizzare la ricerca dei sistemi esposti conferma inoltre il problema già osservato nelle campagne contro WordPress e Joomla che hanno portato all’installazione di webshell, anche se PHP2Shell colpisce direttamente il runtime e non una vulnerabilità specifica del CMS.

CERT-AGID pubblica OpenAI PHP2Shell Checker per verificare le versioni

In Italia, il CERT-AGID ha pubblicato il 22 ottobre 2026 un approfondimento operativo dedicato alla verifica dei server PHP delle amministrazioni e dei fornitori. Il primo strumento segnalato è OpenAI PHP2Shell Checker, che controlla la versione dell’interprete attraverso informazioni disponibili negli header HTTP oppure mediante verifica locale. Il programma, sviluppato in JavaScript ed eseguibile con Node.js, permette di controllare un sito con il comando node phpcheck.js https://example.com oppure l’interprete locale con node phpcheck.js --local. Gli esiti possibili sono OK, VULNERABLE e UNKNOWN. Quest’ultimo non significa che il sistema sia sicuro: indica che non è stato possibile determinare la versione effettivamente utilizzata, ad esempio perché il server non espone il relativo identificativo nelle intestazioni HTTP.

Il documento ufficiale del CERT-AGID precisa che il controllo remoto non tenta di sfruttare le vulnerabilità, limitandosi a confrontare le informazioni disponibili con le versioni corrette. Questo comportamento lo rende utile per una prima ricognizione, ma introduce un limite importante: un server può nascondere il numero di versione PHP, utilizzare un runtime diverso da quello eseguito nella shell oppure ricevere patch tramite backport senza modificare la numerazione principale. Gli amministratori devono quindi verificare il servizio effettivamente eseguito e le correzioni distribuite dal fornitore. Lo strumento è disponibile anche come skill per Codex, con le funzioni phpcheck-url e phpcheck-server, destinate rispettivamente alle verifiche remote e locali. Il controllo automatico facilita l’inventario, ma non sostituisce la documentazione tecnica del sistema.

Assetnote PHP2Shell Scanner esegue test attivi che possono interrompere i servizi

Il secondo strumento segnalato dal CERT-AGID è Assetnote PHP2Shell Scanner, progettato per verificare il comportamento del server attraverso richieste HTTP appositamente costruite. A differenza del checker passivo, il programma invia richieste multipart/form-data e analizza le risposte alla ricerca di errori di memoria, risposte HTTP 500 anomale o interruzioni dei processi PHP-FPM. Il test può essere eseguito su un singolo servizio con python3 scanner.py -u https://example.com -t 1, dopo aver installato le dipendenze indicate nel repository. L’opzione -t 1 limita l’esecuzione a un solo thread, riducendo il carico delle verifiche concorrenti. Lo scanner può analizzare anche elenchi di host e produrre risultati in formato JSON, rendendolo adatto a verifiche programmate sugli asset di un’organizzazione.

La maggiore profondità del controllo comporta però conseguenze operative. La documentazione Assetnote segnala che le richieste di prova possono raggiungere complessivamente circa 29 MiB per percorso analizzato, provocando errori, consumo di risorse o crash dei worker vulnerabili. Il CERT-AGID raccomanda quindi di utilizzare lo scanner esclusivamente su sistemi autorizzati, preferibilmente in ambienti di test o durante finestre di manutenzione. Un risultato positivo richiede ulteriori verifiche per escludere falsi positivi, mentre uno negativo non garantisce l’assenza delle vulnerabilità. Anche il comando php -v presenta limiti, perché può restituire una versione diversa da quella effettivamente utilizzata dal web server. Gli amministratori possono inoltre controllare la presenza di mod_php attraverso apachectl -M e individuare i processi PHP-FPM attivi, ma la conferma definitiva richiede la verifica delle patch installate sul runtime che riceve le richieste HTTP.

Palo Alto conferma l’impatto su PAN-OS e Panorama in attesa delle patch

Un elemento ulteriore riguarda il coinvolgimento dei prodotti dello stesso fornitore che ha quantificato l’esposizione globale. Nel Security Advisory aggiornato il 23 ottobre, Palo Alto Networks conferma che PAN-OS e Panorama sono interessati dalle vulnerabilità PHP2Shell, insieme alle appliance WildFire indicate nel bollettino. Per PAN-OS il problema riguarda specificamente l’interfaccia web di gestione, comprendente HTTPS Web UI e XML API, mentre il produttore precisa che GlobalProtect, Captive Portal e le normali funzionalità del dataplane non sono coinvolti attraverso questo percorso. La gravità assegnata al contesto PAN-OS è CVSS 4.0 8,7, distinta dal punteggio 9,2 attribuito alle vulnerabilità del runtime PHP.

Il produttore ha pubblicato una matrice delle versioni correttive previste per i diversi rami PAN-OS, con disponibilità stimata tra il 26 e il 30 ottobre, mentre per Panorama e alcune appliance WildFire le tempistiche risultano ancora da definire. Al 23 ottobre Palo Alto non dichiara di conoscere sfruttamenti malevoli riusciti contro i propri prodotti, precisazione che distingue l’esposizione del dispositivo dalla conferma di una compromissione. Nell’attesa degli aggiornamenti, raccomanda di limitare l’accesso alle interfacce di gestione agli indirizzi interni attendibili o a una jump box autorizzata. Le protezioni IPS e virtual patching richiedono inoltre una configurazione che permetta l’effettiva ispezione del traffico verso l’interfaccia amministrativa. La vicenda mostra che PHP2Shell non riguarda esclusivamente siti WordPress o applicazioni web tradizionali, ma può coinvolgere componenti incorporati nei sistemi utilizzati per proteggere le reti aziendali.

Continua con:

PHP2Shell, due falle critiche da 9,2: aggiornamento di emergenza per PHP

Vulnerabilità critica in PHP: rischio esecuzione codice remoto

WAF e scanner non sostituiscono la correzione del runtime PHP

La risposta operativa a PHP2Shell deve distinguere individuazione, contenimento e correzione definitiva. Gli strumenti CERT-AGID aiutano a individuare le installazioni interessate, ma non eliminano le vulnerabilità; i sistemi WAF possono invece ridurre il numero di richieste malevole che raggiungono il server, senza garantire una copertura completa. Cloudflare ha comunicato di avere distribuito protezioni automatiche contro PHP2Shell ai clienti che utilizzano il proprio WAF, inclusi quelli del piano gratuito, introducendo controlli capaci di correlare richieste e risposte HTTP. Palo Alto ha rilasciato a sua volta firme di prevenzione per i propri prodotti. Queste misure costituiscono livelli aggiuntivi di difesa, non una dimostrazione che l’interprete PHP sia stato aggiornato. Per aziende, pubbliche amministrazioni ed editori che utilizzano hosting gestiti, il passaggio più importante consiste nel richiedere al fornitore evidenza delle correzioni effettivamente applicate, compresi eventuali backport, verificando l’interprete utilizzato dai servizi esposti e il riavvio dei relativi processi. I sistemi che non possono essere aggiornati devono ricevere restrizioni di accesso proporzionate al rischio, mentre l’analisi retrospettiva dei log dovrebbe partire almeno dal 17 ottobre, data del primo tentativo individuato da Amazon. Le 22,6 milioni di istanze potenzialmente vulnerabili, i milioni di tentativi rilevati e gli strumenti messi a disposizione dal CERT-AGID descrivono tre dimensioni differenti dello stesso problema: esposizione, attività offensiva e capacità di verifica. L’efficacia della risposta dipenderà dalla possibilità di trasformare queste informazioni in aggiornamenti documentabili, senza scambiare il traffico bloccato per una compromissione riuscita e senza considerare un test negativo equivalente alla sicurezza del sistema.