L’avviso congiunto di Commissione, ENISA, CERT-EU e CSIRT europei attiva obblighi già vigenti in capo a titolari, soggetti NIS2 e fabbricanti, rendendo l’inerzia nella rimediazione difficilmente giustificabile.
Cosa è accaduto il 21 ottobre
La Commissione europea, l’ENISA, il CERT-EU, Europol EC3 e la rete dei CSIRT nazionali hanno diffuso una dichiarazione congiunta su due vulnerabilità critiche di PHP, identificate come CVE-2026-109618 e CVE-2026-109619, idonee a consentire l’esecuzione remota di codice non autenticata. L’atto è privo di natura provvedimentale e non crea obblighi nuovi, ma intercetta un reticolo di doveri già vigenti nel Regolamento (UE) 2016/679, nella Direttiva (UE) 2022/2555 recepita dal decreto legislativo 138/2024 e nel Regolamento (UE) 2024/2847. L’avviso tecnico, diffuso dalle massime istituzioni europee competenti e pubblicato sul sito dell’ENISA, acquista rilevanza giuridica perché rende oggettivamente conoscibile il rischio.
La dichiarazione segnala un profilo critico: molti prodotti commerciali e open source incorporano PHP senza che l’utilizzatore ne abbia contezza diretta. Il CSIRT nazionale dei Paesi Bassi ha dovuto costituire un repository dedicato alla mappatura del software di terze parti contenente PHP, fornendo ulteriore evidenza di un deficit informativo strutturale che il Cyber Resilience Act mira a colmare tramite l’obbligo di distinta base del software.
Il quadro normativo che si attiva
L’articolo 32 del GDPR impone al titolare misure tecniche e organizzative adeguate al rischio, tenendo conto dello “stato dell’arte”. Una dichiarazione congiunta diffusa da Commissione, ENISA, CERT-EU e rete CSIRT entra a far parte dello stato dell’arte conoscibile: la mancata applicazione della correzione diventa difficilmente ricondotta all’area del rischio consapevolmente accettato. L’articolo 21 della NIS2, recepito dal decreto legislativo 138/2024, tipizza l’obbligo di gestione delle vulnerabilità per soggetti essenziali e importanti, richiedendo inventario degli asset, monitoraggio degli advisory, pianificazione del patching e verifica della rimediazione.
Il Regolamento (UE) 2024/2847 (Cyber Resilience Act) introduce obblighi per i fabbricanti già dall’11 settembre 2026: la segnalazione di vulnerabilità attivamente sfruttate tramite piattaforma unica, con preallarme entro ventiquattro ore. Dall’11 dicembre 2027 si aggiungeranno obblighi sostanziali di rimediazione tempestiva e la redazione della distinta base del software per ciascun prodotto immesso sul mercato dell’Unione.
La rilevanza giuridica dell’avviso
Un avviso pubblico e datato costituisce un punto di riferimento temporale esterno rispetto al quale misurare la reattività dell’organizzazione nel momento di eventuale contestazione sanzionatoria. Se la patch è stata applicata entro due giorni dalla pubblicazione, la documentazione di quel percorso — ticket, log di deployment, verbali — è elemento di prova a discarico. Se la patch è stata applicata tre mesi dopo, la medesima documentazione diventa prova dell’inerzia. In sede di eventuale accertamento ispettivo, l’organizzazione sarà chiamata a spiegare non tanto perché non sapesse, quanto perché, pur potendo sapere, non abbia agito.
L’articolo 5, paragrafo 2, del GDPR impone al titolare di comprovare il rispetto dei principi di integrità e riservatezza. Una procedura documentata di gestione dell’incidente, che registra formalmente l’avviso, assegna la severità, individua il responsabile della rimediazione e fissa il termine, è ciò che distingue una scelta di rischio consapevole da un’omissione.
Cosa devono fare le imprese
La verifica di applicabilità deve procedere per cerchi concentrici, partendo dai sistemi esposti su internet e dalle applicazioni che trattano dati personali. Non coincide con la semplice ricerca del linguaggio PHP, ma richiede di interrogare l’inventario degli asset software e attivare richieste formali ai fornitori. Si suggerisce di documentare l’ordine di priorità adottato e le ragioni che lo sorreggono: questa documentazione costituisce essa stessa elemento di accountability. L’inventario degli asset deve indicare le componenti di terze parti, il fornitore responsabile della manutenzione e il riferimento contrattuale, predisponendolo in forma compatibile con le distinte base del software che i fabbricanti saranno tenuti a produrre dal Cyber Resilience Act.
Occorre attivare formalmente la procedura di gestione delle vulnerabilità, con registrazione dell’avviso, assegnazione della severità, individuazione del responsabile della rimediazione e fissazione del termine. Laddove la correzione non sia immediatamente applicabile, si deve ricorrere a misure compensative documentate — segregazione di rete, limitazione dell’esposizione, sospensione precauzionale del servizio — assunte a livello gerarchico adeguato. Parallelamente occorre verificare retrospettivamente i log disponibili per accertare se la vulnerabilità sia stata sfruttata, documentando anche l’esito negativo dell’analisi con indicazione delle fonti consultate e del periodo coperto.
Il nodo della catena di fornitura
L’organizzazione media non sviluppa software ma lo acquista, lo noleggia come servizio o lo riceve preinstallato su apparati. La conoscenza della composizione interna è mediata dal fornitore. L’articolo 21, paragrafo 2, lettera d), della NIS2 impone la sicurezza della catena di approvvigionamento, incluse le relazioni con fornitori e prestatori di servizi. La differenza fra un’organizzazione preparata e una impreparata si misura su quello contrattuale e documentale: inventario correlato al fornitore responsabile, clausole che obbligano il fornitore a comunicare tempestivamente l’applicabilità delle vulnerabilità critiche, livelli di servizio differenziati per severità. Si suggerisce di sollecitare formalmente i fornitori con richiesta scritta circa l’applicabilità, i tempi di rimediazione e le misure compensative, registrando la mancata risposta entro termine ragionevole come evento di rischio.
L’informazione al responsabile della protezione dei dati va formalizzata nel flusso informativo, prevedendo che gli advisory di severità critica relativi a sistemi trattanti dati personali siano notificati al DPO contestualmente all’acquisizione. Per i trattamenti soggetti a valutazione d’impatto ai sensi dell’articolo 35 del GDPR, l’emersione di una vulnerabilità critica integra una variazione del rischio che richiede riesame della valutazione, quantomeno quando la correzione non sia immediatamente applicabile.
I profili critici aperti
Nessuna norma fissa un termine per l’applicazione delle patch: l’articolo 32 del GDPR parla di adeguatezza al rischio, l’articolo 21 della NIS2 di proporzionalità, il Cyber Resilience Act di rimediazione “senza ritardo”. Il risultato è che il termine è autodeterminato dall’organizzazione in sede di policy interna e valutato ex post dall’autorità secondo giudizio di ragionevolezza. L’organizzazione prudente può attenuare questa incertezza solo dotandosi di una policy che fissi termini differenziati per severità e per esposizione, applicandola con costanza e documentando le eccezioni. Un’altra questione aperta riguarda l’isolamento delle applicazioni esposte suggerito dalla dichiarazione: sul piano della sicurezza è ineccepibile, ma equivale spesso all’interruzione del servizio, creando conflitto con obbligazioni contrattuali e con la continuità operativa dei soggetti essenziali ai sensi del decreto legislativo 138/2024.
L’approfondimento completo di questo articolo è disponibile su 01magazine.it.
