PHP2Shell, allarme CSIRT Italia: l’81,9% dei servizi PHP risulta vulnerabile

🛡️ Executive Summary

• Il CSIRT Italia rileva 285.149 servizi PHP con versioni potenzialmente vulnerabili a PHP2Shell, pari all’81,9% dei 348.130 servizi con versione identificata.
• Le vulnerabilità CVE-2026-109618 e CVE-2026-109619, entrambe con CVSS 9,2, consentono potenzialmente l’esecuzione remota di codice senza autenticazione.
• La nuova CVE-2026-115560 non dispone ancora di una patch: il CSIRT raccomanda di disabilitare session.upload_progress.enabled e verificare le configurazioni applicative.

L’Italia presenta un’esposizione particolarmente elevata alle vulnerabilità critiche PHP2Shell, con 285.149 servizi PHP potenzialmente vulnerabili e una percentuale dell’81,9% tra quelli per i quali è stata identificata la versione installata. È il dato diffuso dal CSIRT Italia dell’Agenzia per la Cybersicurezza Nazionale nell’allerta del 25 ottobre 2026, che richiama amministratori di sistema, hosting provider e gestori di infrastrutture web a intervenire immediatamente. L’emergenza interessa due vulnerabilità critiche già corrette dal PHP Security Team e una terza, CVE-2026-115560, ancora senza aggiornamento risolutivo, che potrebbe consentire l’esecuzione di codice da remoto in presenza di particolari condizioni applicative. L’allerta nazionale fotografa soprattutto il ritardo nell’aggiornamento delle installazioni esposte su Internet.

Il CSIRT Italia individua 285.149 servizi PHP potenzialmente vulnerabili

Le rilevazioni nazionali contenute nell’allerta AL01/1025/PHP2Shell, elaborate utilizzando dati di esposizione forniti da Censys, individuano 741.523 servizi PHP raggiungibili nel perimetro osservato in Italia. Per 348.130 servizi è stato possibile identificare una versione PHP, mentre 285.149 risultano utilizzare release potenzialmente affette dalle vulnerabilità PHP2Shell e 62.981 presentano una versione corretta, corrispondenti rispettivamente all’81,9% e al 18,1% del campione con versione conosciuta. I dati mostrano inoltre 1.569 servizi aggiornati nelle ultime 24 ore considerate dalla rilevazione. Il dato più significativo non è soltanto la presenza di centinaia di migliaia di installazioni da verificare, ma la distribuzione del rischio: circa quattro servizi su cinque fra quelli identificabili utilizzano versioni associate alle criticità, nonostante le patch siano disponibili dal 21 ottobre. La percentuale non deve tuttavia essere applicata automaticamente all’intero universo dei servizi osservati, poiché per oltre 393.000 installazioni la versione non è stata identificata. Lo stesso CSIRT precisa che l’analisi delle versioni non dimostra la vulnerabilità effettiva di ogni singolo sistema, perché alcune distribuzioni possono aver applicato correzioni tramite backport senza modificare il numero di versione visualizzato. Il risultato resta comunque un indicatore rilevante delle verifiche ancora necessarie, soprattutto considerando che le installazioni PHP costituiscono un componente fondamentale di siti web, applicazioni aziendali e servizi digitali della pubblica amministrazione.

Leggi anche: Vulnerabilità critica in PHP: rischio esecuzione codice remoto

Due vulnerabilità PHP2Shell permettono potenzialmente RCE senza autenticazione

Il nucleo originario di PHP2Shell comprende CVE-2026-109618 e CVE-2026-109619, entrambe classificate con un punteggio CVSS v4.0 di 9,2 e corrette attraverso gli aggiornamenti distribuiti il 21 ottobre. Le due vulnerabilità interessano la gestione interna delle richieste PHP, ma presentano meccanismi differenti. La prima riguarda un problema di corruzione della memoria durante condizioni di esaurimento delle risorse: un’interruzione dell’inizializzazione può lasciare strutture interne in uno stato inconsistente, successivamente interpretato come valido durante le operazioni di pulizia. La seconda interessa invece il mantenimento di uno stato globale non valido tra richieste successive, quando riferimenti a memoria precedentemente liberata possono essere riutilizzati prima della normale inizializzazione. Il produttore considera particolarmente critica la configurazione mod_php, per la quale è stato dimostrato un percorso di sfruttamento attivabile prima dell’esecuzione del codice applicativo. La disponibilità di dettagli tecnici e Proof of Concept pubblici riduce inoltre la complessità necessaria a tentare nuovi attacchi. Non significa che tutti i sistemi individuati siano già compromessi, ma che la superficie di esposizione comprende tecnologie largamente utilizzate e meccanismi capaci di compromettere riservatezza, integrità e disponibilità dei servizi. Il precedente della CVE-2024-4577 sfruttata per distribuire malware attraverso installazioni PHP vulnerabili dimostra come una vulnerabilità del runtime possa trasformarsi in un vettore concreto per compromettere infrastrutture web.

CVE-2026-115560 introduce un nuovo rischio senza aggiornamento disponibile

La situazione si è ulteriormente complicata il 23 ottobre 2026, quando il PHP Security Team ha comunicato l’esistenza della CVE-2026-115560, una vulnerabilità distinta dalle precedenti e non risolta dalle patch già distribuite. Il problema riguarda una particolare interazione tra la serializzazione delle sessioni PHP e il meccanismo di monitoraggio dell’avanzamento degli upload. Perché il percorso vulnerabile sia sfruttabile devono verificarsi contemporaneamente condizioni specifiche: il parametro session.serialize_handler deve essere inizialmente configurato su php_binary oppure php_serialize, successivamente modificato dinamicamente a php mediante ini_set() prima della chiamata a session_start(), mentre la funzionalità session.upload_progress.enabled deve rimanere attiva. È una distinzione sostanziale rispetto alle prime due vulnerabilità: CVE-2026-115560 non può essere individuata semplicemente leggendo la versione del runtime, poiché la sfruttabilità dipende anche dal comportamento dell’applicazione. Il CSIRT Italia richiede di disabilitare la funzione interessata fino alla disponibilità della correzione. La contemporanea esistenza di due vulnerabilità critiche già corrette e di una terza ancora aperta impone quindi un intervento distinto su aggiornamenti software e configurazioni applicative.

Versioni PHP vulnerabili e aggiornamenti da installare immediatamente

Per CVE-2026-109618 e CVE-2026-109619, il CSIRT Italia identifica come vulnerabili le versioni PHP 8.5 precedenti alla 8.5.12, PHP 8.4 precedenti alla 8.4.27, PHP 8.3 precedenti alla 8.3.36 e PHP 8.2 precedenti alla 8.2.35, oltre alle release 8.1 e precedenti, non più supportate direttamente dal progetto PHP. L’intervento non deve limitarsi alla semplice sostituzione di un pacchetto: gli amministratori devono verificare quale versione venga effettivamente caricata dai processi web, distinguendo eventuali installazioni parallele, runtime distribuiti attraverso container, configurazioni PHP-FPM e pacchetti mantenuti dalle distribuzioni Linux. Per i sistemi legacy è necessario controllare la disponibilità di correzioni backport presso il fornitore, evitando di considerare automaticamente vulnerabile un’installazione che conserva una numerazione precedente ma incorpora una patch di sicurezza. Viceversa, l’aggiornamento alle release corrette non elimina CVE-2026-115560, per la quale resta indispensabile verificare le condizioni di configurazione indicate dal produttore. La criticità interessa anche le organizzazioni che gestiscono applicazioni web attraverso fornitori esterni, poiché la sicurezza del codice applicativo non può compensare vulnerabilità presenti nel runtime sottostante. Situazioni analoghe, nelle quali una componente della piattaforma espone indirettamente dati e servizi, sono emerse con le vulnerabilità critiche dei plugin WordPress capaci di consentire esecuzione remota di codice. La priorità operativa deve essere assegnata ai sistemi raggiungibili direttamente da Internet, alle installazioni prive di aggiornamenti gestiti e ai servizi che trattano informazioni sensibili o assicurano funzioni essenziali.

Disabilitare session.upload_progress.enabled e verificare le protezioni WAF

La mitigazione immediata indicata per CVE-2026-115560 consiste nell’impostare il parametro session.upload_progress.enabled=0, disabilitando il meccanismo PHP che permette di monitorare l’avanzamento degli upload attraverso le sessioni. La modifica deve essere applicata alla configurazione utilizzata effettivamente dai processi interessati, verificando che non venga sovrascritta da altre impostazioni e che le applicazioni non dipendano dalla funzionalità disabilitata. Occorre inoltre verificare che la configurazione aggiornata sia stata recepita dai processi PHP. Questa misura protegge dal percorso documentato per la nuova vulnerabilità, ma non sostituisce le patch necessarie per le precedenti criticità. Il CSIRT Italia raccomanda parallelamente di configurare i Web Application Firewall in modalità blocco, quando siano disponibili regole specifiche per le vulnerabilità PHP2Shell, verificandone l’effettiva attivazione. Un WAF configurato soltanto per registrare gli eventi non garantisce infatti la stessa capacità di contenimento di una regola attiva in blocco, mentre filtrare alcune richieste malevole non equivale a correggere il difetto software. Nei casi in cui l’aggiornamento non possa essere effettuato tempestivamente e non siano disponibili mitigazioni efficaci, l’autorità nazionale invita a valutare la temporanea disattivazione dei servizi vulnerabili, fino al ripristino di condizioni di sicurezza adeguate. Una scelta che può incidere sulla continuità operativa, ma che riflette il potenziale impatto di vulnerabilità capaci di portare all’esecuzione di codice sui server esposti.

Continua con:

Zero-day attivi su Windows Defender e patch critiche per Cisco, Apache e PHP

CISA segnala falle critiche in Ivanti EPM e vulnerabilità PHP sfruttata su larga scala

Controlli retrospettivi e rischio per le infrastrutture digitali italiane

L’allerta del 25 ottobre non si limita alla distribuzione delle patch, ma richiede una verifica retrospettiva degli eventi di sicurezza per identificare eventuali tentativi di sfruttamento e indicatori di compromissione. Gli amministratori devono concentrare l’analisi sui log delle richieste HTTP, sulle anomalie nella gestione delle richieste, sugli errori di esaurimento della memoria e sulle interruzioni inattese dei processi PHP, correlando le evidenze con la configurazione reale dei servizi. La presenza di un errore o di un processo terminato non costituisce da sola la prova di un attacco riuscito, ma può rappresentare un segnale da approfondire quando coincide con richieste anomale provenienti dall’esterno. Per le imprese italiane, i fornitori di hosting e le amministrazioni pubbliche, la questione principale diventa quindi la capacità di conoscere e governare l’intera superficie applicativa esposta, compresi servizi legacy, installazioni gestite da terzi e piattaforme che utilizzano PHP senza renderne immediatamente visibile la versione. Gli oltre 285.000 servizi potenzialmente vulnerabili non equivalgono a 285.000 compromissioni accertate, né rappresentano necessariamente altrettanti server fisici distinti, ma costituiscono un segnale significativo della necessità di accelerare aggiornamenti, controlli di configurazione e attività di incident detection. PHP2Shell evidenzia soprattutto il divario tra disponibilità delle correzioni e capacità di applicarle tempestivamente, mentre l’emersione di una terza vulnerabilità ancora senza patch dimostra perché aggiornamento del software, hardening e monitoraggio debbano essere trattati come componenti inseparabili della sicurezza delle infrastrutture web nazionali.