Quando si legge che un attore avanzato come Scattered Spider ha compromesso oltre 40.000 server in poche ore, la reazione istintiva è al panico tecnologico. Si immaginano exploit complessi, tecniche di elusione sofisticate, difese travolte da un’ondata di codice malevolo. La verità è meno spettacolare e molto più imbarazzante: quei server non erano difesi. Erano semplicemente abbandonati.

L’exploit in questione riguarda CVE-2026-41940, una vulnerabilità zero-day in cPanel con punteggio CVSS di 9.8, classificata quindi come critica. Consente l’accesso amministrativo remoto senza autenticazione, il genere di bug che fa sognare gli attaccanti e svegliare di soprassalto i sysadmin. Ma il punto cruciale — quello che i report di sicurezza spesso sfumano con eufemismi — è che la presenza di una vulnerabilità non equivale a un attacco inevitabile. Il vero anello debole non è il codice, ma la governance.

Il mito della vulnerabilità imprevedibile

La narrazione dominante vuole che le zero-day siano armi segrete, impossibili da prevenire. Ma i dati dicono altro. Secondo il Cost of a Data Breach Report 2025 di IBM, il 42% delle vulnerabilità sfruttate in attacchi reali sono già state weaponizzate prima della loro divulgazione pubblica. Questo non significa che le aziende siano impotenti, ma che spesso non fanno neanche il minimo: monitorare le proprie superfici d’attacco, applicare le patch disponibili, verificare lo stato di sicurezza delle dipendenze.

Nel caso di CVE-2026-41940, la finestra di esposizione non è stata ridotta da tecniche avanzate di threat intelligence, ma allargata da una semplice mancanza di processo. cPanel è uno strumento diffusissimo, presente in migliaia di ambienti hosting, spesso gestito da team IT con priorità frammentate. Quando una patch critica viene rilasciata, non basta sapere che esiste: bisogna saperla distribuire, testare, validare — e farlo in tempi che non appartengono al secolo scorso.

La matematica difensiva che nessuno vuole fare

La difesa non si misura in firewall o in sensori AI, ma in cicli operativi. Il tempo medio per applicare una patch critica in molti ambienti aziendali supera ancora le settimane. In alcuni settori, arriva a mesi. Scattered Spider, come altri gruppi criminali, non ha bisogno di essere più furbo: deve solo essere più veloce. E con un ciclo di patching di 24 ore come obiettivo, molti restano indietro.

La risposta non è tecnica, è organizzativa. Bisogna smettere di vedere la gestione delle vulnerabilità come un compito marginale del reparto IT e trattarla come una funzione critica di business continuity. Questo significa:

  • Un inventario accurato delle installazioni di cPanel (e di ogni altro componente a rischio)
  • Un processo automatizzato per il rilevamento e l’applicazione delle patch
  • Test di incident response che non simulino scenari ipotetici, ma replicano attacchi reali con metriche chiare

Misurare il successo con una riduzione del 50% del mean time to respond non è un traguardo ambizioso: è il minimo sindacale. Eppure, quante organizzazioni possono dimostrare di averlo raggiunto?

La domanda che nessuno vuole porsi è semplice: se oggi Scattered Spider colpisce 40.000 server, domani potrebbe colpirne 400.000. Non perché l’attacco è diventato più potente, ma perché la risposta è rimasta immobile. La sicurezza non è una funzione di protezione, ma di velocità. E in questa gara, chi non corre, viene travolto.