PHP2Shell, CERT-AGID: 382 URL a rischio e nuovi strumenti per la PA

🛡️ Executive Summary

• Le URL potenzialmente vulnerabili scendono da 650 a 382: la ricognizione CERT-AGID del 29 ottobre 2026 rileva versioni PHP potenzialmente esposte sull’1,7% dei 22.371 indirizzi IPA analizzati.
• 215 indirizzi inizialmente segnalati dichiarano versioni aggiornate: 47 hanno cambiato stato rispetto al controllo del 26 ottobre, ma la riduzione complessiva non dimostra che tutti i server siano stati corretti.
• AgID pubblica strumenti tecnici su GitHub: gli script consentono di verificare PHP, installare correzioni, applicare mitigazioni temporanee e cercare indicatori di compromissione su sistemi Linux.

PHP2Shell continua a rappresentare un rischio per le infrastrutture web della pubblica amministrazione italiana, ma i dati del CERT-AGID mostrano una progressiva riduzione degli indirizzi che dichiarano versioni potenzialmente vulnerabili dell’interprete PHP. La ricognizione effettuata il 29 ottobre 2026 individua 382 URL a rischio, contro le 650 del 22 ottobre, all’interno dello stesso campione di 22.371 indirizzi censiti nell’Indice dei domicili digitali delle pubbliche amministrazioni (IPA). Parallelamente, l’Agenzia per l’Italia Digitale rende disponibili su GitHub strumenti di verifica, aggiornamento e mitigazione destinati agli amministratori dei sistemi Linux. Il miglioramento statistico non coincide tuttavia con la risoluzione definitiva delle vulnerabilità: i controlli restano passivi, non dimostrano lo sfruttamento delle falle e non possono certificare che tutti i server esclusi dalle successive rilevazioni abbiano effettivamente installato le patch.

PHP2Shell, le URL potenzialmente vulnerabili scendono del 41%

Il bollettino pubblicato dal CERT-AGID il 30 ottobre 2026 presenta i risultati della terza ricognizione dedicata a PHP2Shell, il gruppo di vulnerabilità critiche dell’interprete PHP che ha imposto interventi urgenti agli amministratori dei server esposti su Internet. Il numero di URL che dichiarano una versione potenzialmente vulnerabile passa dalle 650 del 22 ottobre alle 382 del 29 ottobre, con una riduzione netta di 268 indirizzi, pari a circa il 41,2% rispetto alla rilevazione iniziale. Il dato corrisponde all’1,7% dei 22.371 indirizzi IPA analizzati, contro circa il 2,9% della prima verifica. Il confronto è significativo perché il campione è rimasto invariato, evitando che le differenze dipendano dall’aggiunta o dalla rimozione di indirizzi dall’elenco esaminato.

L’indicatore più importante riguarda però le 215 URL inizialmente segnalate che ora dichiarano una versione aggiornata, circa un terzo delle 650 iniziali. Di queste, 47 hanno cambiato stato rispetto al controllo del 26 ottobre, quando gli indirizzi dichiaratamente aggiornati erano 168. La progressione suggerisce che le comunicazioni dell’Agenzia e gli interventi degli amministratori stiano producendo effetti, ma il CERT-AGID precisa che la versione dichiarata dal server non costituisce una certificazione della configurazione effettivamente in esecuzione. Per stabilire se le vulnerabilità siano state corrette occorre verificare direttamente i pacchetti installati e le eventuali patch distribuite dai fornitori.

Leggi anche: PHP2Shell, 650 URL della PA a rischio: AWS rimuove le CA eMudhra

Perché la diminuzione delle segnalazioni non equivale a 268 server corretti

La differenza tra URL non più segnalate come potenzialmente vulnerabili e sistemi effettivamente aggiornati è centrale nell’interpretazione dei risultati. Alcuni indirizzi possono avere smesso di esporre pubblicamente la versione PHP, mentre altri possono essere risultati temporaneamente irraggiungibili. In entrambi i casi l’indirizzo esce dalla categoria utilizzata nella ricognizione senza che sia necessariamente intervenuta una correzione del software. Nascondere le informazioni sulla versione riduce la possibilità di identificare immediatamente un sistema obsoleto, ma non elimina una vulnerabilità eventualmente presente nell’interprete. Il CERT-AGID sottolinea inoltre che la verifica non ha utilizzato payload, tentativi di sfruttamento o procedure invasive. Sono stati esaminati esclusivamente gli indirizzi inclusi nell’elenco IPA, senza estendere automaticamente l’indagine a sottodomini, applicazioni o servizi non censiti. Pertanto, il valore di 382 non rappresenta il numero complessivo dei server PHP vulnerabili nella pubblica amministrazione italiana. Le amministrazioni già segnalate continuano a ricevere solleciti quando i sistemi dichiarano versioni potenzialmente esposte, mentre i nuovi casi vengono notificati ai rispettivi responsabili.

CVE-2026-109618 e CVE-2026-109619: il problema è nell’interprete PHP

Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 sono classificate nel repository tecnico AgID dedicato a PHP2Shell con gravità CVSS 9,2 e possono consentire, nelle configurazioni interessate, l’esecuzione remota di codice senza autenticazione attraverso richieste HTTP opportunamente costruite. La documentazione indica come configurazione direttamente confermata Apache con mod_php, mentre alcune condizioni di esposizione possono riguardare anche PHP-FPM. Le versioni corrette indicate dal progetto sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per i rami PHP 7.4, 8.0 e 8.1, ormai fuori supporto, sono disponibili correzioni minime e backport distribuiti attraverso specifici repository o fornitori. Queste patch intervengono sulle due vulnerabilità PHP2Shell, ma non risolvono automaticamente gli altri problemi di sicurezza accumulati dopo la fine del supporto. Un aspetto particolarmente importante per i siti istituzionali è che aggiornare soltanto WordPress, Drupal o i rispettivi plugin non corregge PHP2Shell, perché il difetto riguarda l’interprete utilizzato dal server. Dopo l’installazione delle correzioni occorre inoltre riavviare Apache o PHP-FPM, evitando che processi già attivi continuino a eseguire codice vulnerabile. Le due CVE erano già state analizzate nell’approfondimento sulle patch PHP rilasciate contro le vulnerabilità RCE senza autenticazione.

AgID pubblica gli script per Ubuntu, Debian, Fedora e RHEL

La novità operativa del 30 ottobre è la disponibilità degli strumenti sviluppati da AgID per aiutare amministrazioni e fornitori a intervenire direttamente sui server. Il progetto PHP2Shell, pubblicato nel ramo beta, comprende due script Bash principali: php-cve-fix-ubuntu.sh, destinato ai sistemi basati su Ubuntu e Debian, e php-cve-fix-fedora.sh, progettato per Fedora, RHEL, Rocky Linux e AlmaLinux. Entrambi permettono di controllare i rami PHP installati, verificare la disponibilità degli aggiornamenti e applicare, quando richiesto, correzioni e mitigazioni. La documentazione distingue chiaramente le operazioni che modificano il sistema da quelle di sola verifica. L’opzione --check controlla lo stato dei pacchetti senza applicare modifiche, mentre --ioc effettua una ricerca non invasiva di possibili indicatori di compromissione. Per i sistemi Ubuntu e Debian è prevista anche l’opzione --aggiungi-sury, destinata a utilizzare il repository PHP di Ondřej Surý in determinate condizioni; sui sistemi della famiglia Red Hat è disponibile l’equivalente --aggiungi-remi, con limitazioni dipendenti dalla versione della distribuzione. La presenza del codice su GitHub non significa però che gli strumenti siano stati validati su ogni piattaforma supportata. Il repository documenta test effettuati su Ubuntu 24.04, prove specifiche su Ubuntu 20.04 e verifiche simulate per alcune funzionalità Fedora/RHEL. L’esecuzione su ambienti di produzione richiede quindi una valutazione tecnica preventiva, soprattutto quando vengono coinvolti repository aggiuntivi, configurazioni personalizzate e differenti versioni PHP installate contemporaneamente.

Mitigazioni e indicatori di compromissione: cosa verificano gli strumenti

Quando non è possibile applicare immediatamente una correzione, gli script possono introdurre mitigazioni temporanee, indicate attraverso l’opzione --mitiga. La documentazione comprende, tra le altre misure, la disattivazione di session.upload_progress.enabled, limitazioni della dimensione delle richieste POST e interventi sulla gestione della memoria di PHP-FPM. Sono modifiche che possono influenzare il comportamento delle applicazioni e che non sostituiscono l’installazione delle patch. Il repository prevede controlli sulla validità delle configurazioni prima dei riavvii e meccanismi di ripristino per alcune modifiche ai pool PHP-FPM. L’opzione --ioc esamina invece i log a partire dal 17 ottobre 2026, data indicata nella documentazione come riferimento per i primi tentativi di sfruttamento osservati. Le verifiche comprendono richieste POST associate a errori server, crash dei processi, messaggi di esaurimento della memoria, processi figli sospetti e modifiche ai file PHP nelle directory pubblicate. Gli amministratori possono inoltre fornire un elenco di indirizzi IP da ricercare nei log. Un indicatore non costituisce automaticamente la prova di una compromissione: errori HTTP e modifiche ai file possono avere spiegazioni legittime. Se emergono elementi sospetti, la documentazione raccomanda di conservare i log e gli snapshot prima di intervenire sul sistema, coinvolgendo i responsabili della sicurezza per verificare la natura dell’evento.

Continua con:

CISA inserisce PHP2Shell nel KEV: patch urgenti sui server italiani

PHP2Shell, attacchi riusciti: 35 shell eseguite su tre server PHP

La pubblica amministrazione deve verificare le patch, non soltanto la versione dichiarata

Il miglioramento registrato dal CERT-AGID rappresenta un segnale positivo nella risposta italiana a PHP2Shell, soprattutto considerando che oltre duecento indirizzi precedentemente segnalati dichiarano ora versioni aggiornate. Il risultato non deve però essere interpretato come una certificazione di sicurezza dei sistemi, né come una misura completa dell’esposizione della pubblica amministrazione. L’obiettivo operativo rimane verificare la versione PHP realmente installata, l’eventuale presenza di backport, il riavvio dei servizi e gli indicatori di compromissione, estendendo i controlli anche agli applicativi non compresi nell’elenco IPA. Gli strumenti AgID offrono un supporto concreto, ma devono essere utilizzati da personale qualificato, inizialmente in ambienti di replica, con backup verificati e finestre di manutenzione pianificate. Il numero delle URL potenzialmente vulnerabili è diminuito, ma la sicurezza effettiva dipende dalla capacità delle amministrazioni di dimostrare che i sistemi sono stati corretti e che eventuali attacchi precedenti sono stati individuati.