Una vulnerabilità di migliaia di siti web riporta al centro una domanda che riguarda chi guida un’azienda o un ente: quanto conosciamo davvero la nostra infrastruttura?
Negli ultimi giorni il termine «Black October» ha alimentato discussioni e preoccupazioni nel mondo della cybersecurity.
Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti d’emergenza per correggere due vulnerabilità critiche, ribattezzate PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Il punteggio di gravità è 9,2 su 10.
PHP è il linguaggio su cui funziona gran parte del web: siti aziendali, portali clienti, e-commerce, servizi di enti pubblici, e piattaforme come WordPress, Drupal, Joomla e Magento. In determinate condizioni, un aggressore può eseguire comandi su un server da remoto, senza password. Può così prendere il controllo del sistema o accedere a dati riservati. Exploit dimostrativi sono già pubblici, quindi il tempo per intervenire è poco.
Il punto centrale non è stabilire se ogni sito che utilizza PHP sia vulnerabile. Non lo è automaticamente. Il problema è sapere quali sistemi utilizzano versioni interessate, quali sono esposti e quali correzioni siano state effettivamente applicate.
Perché una vulnerabilità del runtime non riguarda soltanto il reparto IT. Può coinvolgere la disponibilità dei servizi, la riservatezza dei dati, la continuità operativa, i rapporti con i clienti e, nei casi pertinenti, gli obblighi normativi dell’organizzazione.
La vera questione: quanto conosciamo la nostra infrastruttura?
PHP è utilizzato in numerosi siti, portali e applicativi web. È presente in molti ambienti basati su WordPress, Drupal, Joomla e Magento, oltre che in applicazioni sviluppate su misura.
Ma sapere che la propria azienda utilizza un CMS(Content Management System), non significa conoscere l’intero ambiente tecnologico che lo sostiene.
PHP potrebbe essere eseguito su server interni, macchine virtuali, container, piattaforme cloud o servizi gestiti da fornitori esterni. Potrebbe essere presente in applicazioni poco utilizzate, ambienti di test dimenticati o portali che non rientrano più nei normali processi di manutenzione.
Ecco perché la prima domanda da porsi non è «Abbiamo aggiornato WordPress?», ma:
Sappiamo esattamente dove gira PHP nella nostra infrastruttura, quali versioni sono in uso e chi è responsabile della loro sicurezza?
Se queste informazioni non sono disponibili o sono incomplete, il problema esiste già, indipendentemente dalla vulnerabilità del momento.
Tre domande che ogni CEO e IT Manager dovrebbe porsi
1. Sappiamo quali sistemi sono esposti a Internet?
Un inventario aggiornato non è soltanto uno strumento tecnico: è la base per decidere dove intervenire, con quale urgenza e con quali risorse.
2. Quanto tempo impieghiamo a individuare e correggere una vulnerabilità critica?
Un ciclo di manutenzione esclusivamente mensile può non essere sufficiente per vulnerabilità critiche
3. Se il sistema fosse già stato compromesso, ce ne accorgeremmo?
NIS2: il 31 ottobre 2026 è dietro l’angolo
La NIS2 è la normativa europea sulla sicurezza informatica, recepita in Italia con il D.Lgs. 138/2024 e seguita dall’Agenzia per la Cybersicurezza Nazionale (ACN). Riguarda oltre ventimila organizzazioni italiane, tra imprese e pubbliche amministrazioni.
- Da gennaio 2026 è in vigore l’obbligo di notifica degli incidenti significativi (preallerta entro 24 ore, notifica entro 72).
- Entro il 31 ottobre 2026 i soggetti inseriti nell’elenco NIS nel 2025 devono avere operative le misure di sicurezza di base definite dall’ACN.
- Dopo quella data, l’attenzione passa dall’accompagnamento alle verifiche.
- non tutte le organizzazioni però hanno la stessa scadenza. Il termine è di 18 mesi dalla comunicazione di inserimento in elenco, quindi va controllata la propria comunicazione.
- La NIS2 non chiede una policy archiviata, ma evidenze che le misure funzionino. Nel caso di PHP2Shell, un’organizzazione dovrebbe poter mostrare:
- l’inventario dei sistemi e delle responsabilità;
- come individua, valuta e corregge le vulnerabilità;
- come gestisce eccezioni e sistemi non aggiornabili;
- come controlla fornitori e dipendenze tecnologiche;
- come gestisce e notifica gli incidenti;
- come sono coinvolti i vertici, che hanno responsabilità dirette.
La conformità non si esaurisce nella documentazione. Le procedure devono essere operative, proporzionate al rischio e verificabili. Gestire bene questa falla è una prova generale di conformità: i documenti diventano azioni, oppure restano sulla carta.
Perché la scelta del partner tecnologico conta
Un partner tecnologico può contribuire in modo decisivo alla gestione del rischio, soprattutto quando l’organizzazione non dispone internamente di tutte le competenze o delle risorse necessarie.
La scelta del partner deve essere coerente con il rischio che si intende governare. Un fornitore efficace non sostituisce le responsabilità dell’azienda: le rende più gestibili, trasparenti e misurabili.
La domanda finale per chi guida un’organizzazione: Se domani venisse pubblicata una nuova vulnerabilità critica, sapremmo individuare in poche ore i sistemi coinvolti, stabilire le priorità, attivare i fornitori e dimostrare cosa è stato fatto?
Se la risposta non è documentata, c’è un margine di rischio da affrontare.
PHP2Shell è un caso concreto, ma la questione riguarda un problema più ampio: la capacità di sapere quali tecnologie sostengono i servizi aziendali, dove si trovano, chi le gestisce e quanto rapidamente possono essere messe in sicurezza.
Il primo passo è una verifica, non un acquisto
Prima di introdurre nuove tecnologie serve capire dove si è. Una valutazione iniziale dovrebbe produrre un inventario dei sistemi coinvolti, le priorità, un piano di correzione e un quadro delle responsabilità. Da lì si decide cosa gestire internamente e dove farsi affiancare.
Non tutte le organizzazioni hanno bisogno dello stesso strumento o dello stesso servizio. Prima di introdurre nuove tecnologie, è utile verificare lo stato reale dell’infrastruttura e individuare le lacune più importanti
Una valutazione iniziale dovrebbe produrre almeno quattro risultati: inventario dei sistemi interessati, analisi delle priorità, piano di remediation e quadro delle responsabilità
Da lì è possibile decidere quali interventi gestire internamente e dove sia opportuno coinvolgere un partner specializzato
Un audit consente di ottenere una fotografia documentata della situazione, identificare le criticità prioritarie e definire un piano di intervento concreto, proporzionato al rischio e alle esigenze dell’organizzazione.
La sicurezza inizia dalla visibilità. La resilienza si costruisce con verifiche concrete, responsabilità chiare e interventi misurabili.
Non aspettare la prossima vulnerabilità per scoprire dove sei esposto.
Contatta il team CLT Group per valutare un audit della tua infrastruttura IT: individuiamo insieme priorità, azioni necessarie e misure per proteggere la continuità dei tuoi servizi digitali.
Richiedi un audit
La sicurezza inizia dalla visibilità. La resilienza si costruisce con verifiche concrete, responsabilità chiare e interventi misurabili.