PHP2Shell: vulnerabilità che

In sintesi

• Le due vulnerabilità PHP2Shell riguardano il funzionamento interno del linguaggio PHP, non errori nel codice scritto dalle agenzie.
• Alcuni siti governativi e servizi pubblici europei sono stati disattivati a titolo precauzionale in attesa di verifiche.
• Il Cyber Resilience Act (Regolamento UE 2024/2847) impone già obblighi di notifica entro 24 ore per vulnerabilità sfruttate attivamente, in vigore dall’11 dicembre 2024.
• La domanda giusta da fare al fornitore non è “avete controllato il sito” ma “a che versione di PHP gira il server e quando è stata aggiornata”.
• Serve una conferma scritta, non una rassicurazione a voce. In caso di incidente, è l’unica prova che la verifica sia stata fatta.

Cosa sono le falle PHP2Shell e perché non dipendono da te

PHP è il linguaggio su cui girano WordPress, Joomla, Magento e una fetta consistente del web italiano. PHP2Shell è il nome con cui si indicano due vulnerabilità scoperte dentro il funzionamento interno di PHP stesso, non in uno dei siti costruiti sopra. La distinzione conta: non è un bug nel tema grafico, non è un plugin scritto male, non è una personalizzazione frettolosa dell’agenzia che ha costruito il sito. È un problema nelle fondamenta, che coinvolge applicazioni diverse tra loro anche quando il codice del singolo sito è ineccepibile, come riportato da Repubblica.

La conseguenza si vede già nei fatti. Alcuni siti governativi e servizi pubblici europei sono stati spenti temporaneamente, non perché il loro codice fosse difettoso, ma perché il server girava su una versione di PHP esposta al problema. A scegliere lo spegnimento preventivo sono state infrastrutture con team di sicurezza dedicati e risorse che la maggior parte delle aziende italiane non ha. Qui emerge il primo problema concreto: chiedere al fornitore a quale versione di PHP gira il server di produzione, non quello di test, e pretendere un numero preciso, tipo “8.2.24”, non un generico “è tutto aggiornato”.

Il caso di chi gestisce dati sensibili attraverso il proprio sito

Prendiamo il caso di una clinica privata che raccoglie dati sanitari dei pazienti tramite un modulo online: prenotazioni, referti, anamnesi. Chi gestisce quella clinica ha probabilmente delegato per intero la sicurezza tecnica a un fornitore esterno, fidandosi di una rassicurazione verbale ricevuta mesi o anni prima. È una scelta comprensibile: non ci si aspetta che un medico sappia leggere un changelog di PHP.

Il problema arriva nel momento in cui qualcosa va storto. Se quei dati vengono esposti perché il server non era aggiornato, “mi avevano detto che era tutto a posto” non regge davanti al paziente che fa causa, e non regge davanti al Garante per la protezione dei dati personali, che chiederà documentazione, non ricordi di una telefonata. La differenza tra una clinica che ha una email con data e versione PHP confermata e una clinica che ha solo un ricordo vago di una rassicurazione è la differenza tra una responsabilità gestita e una responsabilità subita.

Questo è il motivo per cui la domanda da fare al fornitore deve cambiare natura: non più “è tutto sicuro?”, che invita una risposta vaga quanto la domanda, ma “quando è stato applicato l’ultimo aggiornamento di sicurezza su PHP, e dove posso vederlo scritto?”. Non è burocrazia aggiuntiva: è l’unico modo per trasformare una fiducia informale in qualcosa che regge in sede di contestazione.

Il collegamento con il Cyber Resilience Act

Il Cyber Resilience Act, Regolamento UE 2024/2847, è in vigore dall’11 dicembre 2024 e prevede un obbligo concreto per chi produce o distribuisce software con elementi digitali, categoria che comprende praticamente ogni sito o applicazione connessa a internet. L’articolo 14 del regolamento impone la notifica di vulnerabilità attivamente sfruttate entro 24 ore all’ente competente. Ventiquattro ore, non ventiquattro giorni.

PHP2Shell è esattamente il tipo di evento che dovrebbe far scattare questo meccanismo: una vulnerabilità nota, sfruttabile, con impatti già documentati su servizi pubblici. Il punto debole della norma, però, è proprio nell’applicazione pratica: l’obbligo esiste sulla carta, ma resta da vedere quante agenzie web italiane sappiano effettivamente di esserne soggette. Se un’agenzia rivende soluzioni con il proprio marchio, costruite su stack tecnologici di terzi, il CRA la considera fabbricante a tutti gli effetti, indipendentemente da cosa dica il contratto con chi ha scritto il codice originale.

Questo significa che il fornitore non ha solo una responsabilità tecnica verso il cliente, ha un obbligo legale di notifica verso le autorità, con scadenze precise e verificabili. Se non sa rispondere alla domanda “avete già notificato questa vulnerabilità secondo l’articolo 14”, il sospetto legittimo è che non conosca i propri obblighi normativi, più che li stia volutamente ignorando. È un problema di enforcement più che di malafede: la norma c’è, ma mancano ancora verifiche sistematiche su chi la sta effettivamente rispettando.

Cosa chiedere, concretamente, e come farlo per iscritto

Le domande da porre al fornitore sono tre, dirette e verificabili: a che versione di PHP gira il server di produzione e quando è stato aggiornato l’ultima volta; se è stata applicata la patch specifica per PHP2Shell, con data dell’intervento; qual è il piano per i prossimi aggiornamenti di sicurezza critici, non quelli di routine.

La parte che fa davvero la differenza non è la domanda in sé, è il formato della risposta. La conferma deve arrivare per email o in un documento firmato, mai in una chiamata o in un messaggio vocale. Non perché chi gestisce un’attività debba trasformarsi in un tecnico di sistema, ma perché in caso di incidente quella email è l’unica cosa che dimostra due fatti: che la verifica è stata fatta, e quando è stata fatta. Tornando al caso della clinica: quella stessa email, conservata per sei mesi, è ciò che separa una risposta solida al Garante da un’ammissione implicita di negligenza.

Il modo più pratico per partire è inviare oggi stesso una email con le tre domande, chiedendo risposta scritta entro cinque giorni lavorativi, e conservarla in un posto dove sia facilmente reperibile anche mesi dopo, quando l’urgenza del momento sarà passata.

Domande correlate

PHP2Shell colpisce anche WordPress e Joomla?

Sì, potenzialmente, perché entrambi girano su PHP. La falla non è nel codice di WordPress o Joomla in sé, ma nel linguaggio sottostante. Se il server usa una versione vulnerabile, qualsiasi applicazione costruita sopra è esposta, indipendentemente dal sistema di gestione dei contenuti scelto.

Devo spegnere il sito mentre aspetto risposta dal fornitore?

Non necessariamente, ma dipende da quanto è esposto il sito: dati sensibili, area clienti, pagamenti online. Alcuni enti pubblici l’hanno fatto in via precauzionale. Se il fornitore non sa dire lo stato del server entro pochi giorni, la prudenza è giustificata.

Il CRA si applica anche alla mia piccola agenzia web?

Se l’agenzia sviluppa o distribuisce software con il proprio marchio, anche costruito su componenti di terzi, il Cyber Resilience Act la considera fabbricante. Questo la espone agli obblighi dell’articolo 14, comprese le notifiche entro 24 ore per vulnerabilità sfruttate attivamente.

Cosa scrivo se il fornitore non risponde entro i termini?

Metti per iscritto che hai richiesto conferma della patch e dei tempi di notifica secondo gli obblighi del Cyber Resilience Act. Specifica che l’assenza di risposta costituisce inadempienza contrattuale rispetto agli standard di sicurezza attesi, soprattutto se vengono trattati dati sensibili.

Fonti:

• Le falle riguardano il funzionamento interno di PHP e possono quindi coinvolgere applicazioni differenti - Repubblica: https://www.repubblica.it/tecnologia/2026/10/21/news/php2shell_ia_due_falle_web-425663861/ (accesso ottobre 2026)
• Regolamento (UE) 2024/2847, Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2847 (accesso ottobre 2026)