Le due vulnerabilità critiche del motore PHP note come PHP2Shell, corrette il 21 ottobre 2026, sono ormai oggetto di sfruttamento esteso in rete e in Italia la maggior parte dei servizi PHP esposti con versione identificabile non risulta ancora aggiornata.
L’attenzione si è concentrata finora su siti web e CMS, ma la vicenda presenta un secondo livello altrettanto rilevante.
PHP, infatti, non gira soltanto sui server che ospitano portali e negozi online. È incorporato anche nelle interfacce di gestione di firewall, sistemi di archiviazione di rete, centralini e numerosi software aziendali, dove la versione del linguaggio viene scelta e aggiornata dal produttore e non dall’organizzazione che utilizza il dispositivo.
Proprio per questo quello di PHP2Shell rappresenta uno dei primi casi di ampia portata a cui si applicano gli obblighi di segnalazione introdotti dal Cyber Resilience Act europeo, applicabili dall’11 settembre 2026, e mette in luce come la responsabilità della sicurezza si distribuisca lungo una catena che va dal progetto open source fino all’utente finale.
Indice degli argomenti
Le falle
Le vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619 e valutate entrambe 9,2 su 10 secondo lo standard CVSS 4.0, derivano da una gestione non corretta della memoria in condizioni di errore e consentono, in determinate configurazioni, l’esecuzione di codice da remoto senza autenticazione.
Il gruppo di threat intelligence di Amazon ha individuato un primo tentativo di sfruttamento già il 17 ottobre, quattro giorni prima della pubblicazione delle correzioni, e ha poi descritto lo sfruttamento come ormai diffuso, invitando a condurre le verifiche a partire da quella data e non dal giorno della patch.
Sul fronte nazionale, il CSIRT Italia ha condotto un’analisi dell’esposizione del Paese: secondo i dati disponibili al 25 ottobre, su 741.523 servizi PHP rilevati in Italia, 285.149 utilizzano versioni potenzialmente vulnerabili, pari all’81,9% di quelli per cui è stato possibile identificare la versione in uso.
L’Agenzia per la Cybersicurezza Nazionale raccomanda l’aggiornamento immediato, la configurazione in modalità di blocco delle regole specifiche nei firewall applicativi e, in assenza di mitigazioni efficaci, la valutazione di porre temporaneamente offline i servizi interessati.
Un monitoraggio di questo tipo offre a imprese e amministrazioni un quadro concreto della propria esposizione, ma il dato si riferisce ai servizi web identificabili dall’esterno e non può restituire la parte meno visibile del problema.
L’elenco dei software con dipendenza da PHP
Il difetto, infatti, si trova nell’interprete e non nelle singole applicazioni. Ne consegue che qualunque prodotto che utilizzi PHP per gestire richieste web è potenzialmente coinvolto, che si tratti di un sito istituzionale o dell’interfaccia di amministrazione di un apparato di rete.
Il centro nazionale per la sicurezza informatica dei Paesi Bassi ha pubblicato un elenco dei software con dipendenza da PHP, aggiornato man mano che i fornitori completano le proprie verifiche, che comprende centinaia di prodotti, molti dei quali ancora in fase di analisi.
I casi più rilevanti
Tra i casi più significativi figura quello di Palo Alto Networks, che ha confermato il coinvolgimento dell’interfaccia web di gestione e delle API XML dei propri firewall e della piattaforma Panorama, con correzioni distribuite progressivamente per i diversi rami del sistema operativo e la raccomandazione, nell’attesa, di limitare l’accesso alle interfacce di gestione ai soli indirizzi interni attendibili.
Anche QNAP ha indicato come interessati i sistemi operativi dei propri dispositivi di archiviazione di rete e diverse applicazioni, ha rilasciato firmware corretti per i sistemi principali e ha raccomandato, per i componenti non ancora aggiornati, di non esporre i dispositivi direttamente su Internet.
La finestra di esposizione
In questi contesti l’amministratore non può sostituire in autonomia l’interprete, come avviene su un server web, ma deve attendere l’aggiornamento predisposto dal fornitore.
Il tempo che intercorre tra la correzione del progetto PHP e la sua effettiva disponibilità sul dispositivo diventa così una finestra di esposizione che dipende da soggetti diversi dall’organizzazione che utilizza l’apparato.
I 3 soggetti da cui dipende un componente software condiviso
Da quanto sopra esposto appare chiaro, quindi, come la sicurezza di un componente software condiviso non dipenda da un unico soggetto, ma sia ripartita tra più attori, ciascuno con compiti e tempi propri.
Si possono distinguere almeno tre soggetti: chi sviluppa il componente, chi lo integra nei propri prodotti e chi, infine, lo utilizza.
Il primo è il progetto open source, cioè la comunità di sviluppatori, sostenuta in questo caso anche dalla PHP Foundation, che scrive e mantiene l’interprete, riceve le segnalazioni di vulnerabilità, ne verifica la fondatezza, progetta le correzioni e le pubblica sotto forma di nuove versioni.
Si tratta di un lavoro affidato in larga parte a un numero limitato di persone, chiamate a conciliare la rapidità dell’intervento con la necessità di non compromettere il funzionamento delle numerosissime applicazioni che dipendono dallo stesso codice.
La PHP Foundation ha ricostruito con trasparenza le ragioni per cui un problema intravisto già durante un audit del 2024 non era stato risolto prima, indicando la difficoltà di soluzioni che rischiavano di introdurre incompatibilità, un processo decisionale da rafforzare e il numero ridotto di sviluppatori con una conoscenza approfondita del motore, e ha segnalato un forte aumento delle segnalazioni ricevute, molte delle quali risultate non valide o duplicate.
Gli altri due soggetti
Il secondo soggetto è costituito dai produttori che incorporano PHP nei propri prodotti e che devono integrare le correzioni, verificarne la compatibilità e distribuirle ai clienti.
Peraltro, il progetto non rilascerà correzioni ufficiali per i rami 8.1 e precedenti, ormai fuori supporto, e per questi ambienti la protezione dipende dai fornitori in grado di offrire aggiornamenti retroportati 8 .
Infine, il terzo soggetto è l’organizzazione utente, che deve sapere dove PHP è in esecuzione e applicare gli aggiornamenti.
I confini tra i soggetti coinvolti non sono sempre netti: per esempio, QNAP precisa che i propri aggiornamenti non coprono il PHP eseguito all’interno dei container o delle applicazioni di terze parti installate sui dispositivi, per i quali occorre rivolgersi ai rispettivi fornitori.
PHP2Shell, cosa disciplina il CRA
Proprio la posizione dei produttori, che integrano nei propri prodotti componenti sviluppati da altri e ne rispondono verso i clienti, è quella che il Cyber Resilience Act disciplina per prima.
Dall’11 settembre 2026 i produttori di prodotti con elementi digitali sono tenuti a notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei propri prodotti, con un preallarme entro 24 ore dal momento in cui ne vengono a conoscenza e una notifica completa entro 72 ore, attraverso la piattaforma unica di segnalazione istituita dall’ENISA in stretta collaborazione con la rete dei CSIRT.
Cosa prevede a regime il regolamento
PHP2Shell è emerso a sei settimane dall’applicazione di questi obblighi, e ne costituisce una delle prime applicazioni di ampia portata, perché ogni produttore che integra un PHP vulnerabile in un prodotto immesso sul mercato europeo dovrà valutare se la vulnerabilità risulti effettivamente sfruttata nel proprio prodotto, condizione che fa scattare l’obbligo di notifica.
Diverso è il regime previsto per gli steward open source, cioè i soggetti diversi dai produttori che sostengono in modo continuativo lo sviluppo di software libero destinato ad attività commerciali, ai quali il regolamento chiede di adottare una politica di sicurezza documentata e di cooperare con le autorità di vigilanza, e per i quali gli obblighi di segnalazione si applicheranno soltanto dall’11 dicembre 2027.
Ne deriva un’asimmetria temporanea, coerente con l’impostazione graduale del regolamento, per cui oggi l’obbligo di segnalazione ricade su chi incorpora il componente più che su chi lo mantiene.
A regime, inoltre, il regolamento prevede che i produttori che individuano una vulnerabilità in un componente, anche open source, la segnalino a chi lo sviluppa o lo mantiene, rafforzando lo scambio di informazioni lungo l’intera catena.
Le priorità sul piano operativo
Sul piano operativo, le indicazioni delle autorità e dei fornitori convergono su alcune priorità.
La prima riguarda l’inventario, che deve estendersi oltre i siti web e i portali fino a comprendere interfacce di gestione di firewall e router, captive portal delle reti ospiti, dispositivi di archiviazione, centralini, sistemi di ticketing e strumenti di monitoraggio, verificando per ciascuno la versione di PHP effettivamente in uso e le reti da cui è raggiungibile; l’elenco pubblicato dal centro olandese rappresenta un utile punto di partenza.
La seconda riguarda la riduzione dell’esposizione, perché le interfacce di amministrazione non dovrebbero essere raggiungibili direttamente da Internet, ma soltanto da reti attendibili o tramite accessi controllati, come raccomandano gli stessi fornitori in attesa delle correzioni.
La terza riguarda il rapporto con i fornitori, ai quali è opportuno chiedere in modo formale se i prodotti in uso contengano PHP, in quale versione e con quali tempi di aggiornamento, includendo questi aspetti anche nei requisiti contrattuali e nelle procedure di acquisto, in particolare per le pubbliche amministrazioni.
Infine, poiché i primi tentativi di sfruttamento hanno preceduto la pubblicazione delle correzioni, l’ACN raccomanda verifiche retrospettive sui log e sugli eventi di sicurezza anche sui sistemi già aggiornati, tenendo conto che il 23 ottobre il progetto PHP ha segnalato un’ulteriore vulnerabilità, la CVE-2026-115560, legata a una configurazione specifica e ancora priva di patch, per la quale resta consigliata la disattivazione della funzione di monitoraggio dell’avanzamento degli upload.
PHP2Shell e il quadro normativo europeo: il ruolo del CRA
PHP2Shell conferma una dinamica già osservata con Heartbleed nel 2014 e con Log4Shell nel 2021, in cui un componente condiviso da un numero molto elevato di prodotti diventa il punto di partenza di un’emergenza globale. Rispetto a quei casi, però, il contesto è cambiato sotto due profili.
Da un lato, gli strumenti di intelligenza artificiale hanno contribuito a individuare vulnerabilità rimaste nascoste per anni e riducono il tempo necessario per trasformarle in attacchi, accorciando la finestra a disposizione di chi difende.
Dall’altro, l’Unione europea dispone ora di un quadro normativo che attribuisce responsabilità precise ai produttori e che, nei prossimi mesi, consentirà di valutare quanto la segnalazione obbligatoria contribuisca a rendere più rapida e coordinata la risposta.
Per imprese e amministrazioni la lezione più concreta riguarda la visibilità, perché conoscere dove si trovano i componenti condivisi all’interno della propria infrastruttura, compresi quelli nascosti negli apparati, è la condizione necessaria per poterli aggiornare in tempo utile.
Partecipa alla community