Microsoft corregge un numero record di vulnerabilità. La più urgente è uno zero-day già sfruttato che fa sparire l'avviso sui file scaricati. Ecco come dare le priorità.
Un numero che spaventa, ma non va letto così
Più di 1.400 vulnerabilità corrette in un colpo solo. Da dove si comincia? Se lo sono chiesto molti reparti IT dopo il Patch Tuesday di ottobre, pubblicato da Microsoft il 13 ottobre. Il totale cambia un po' a seconda di chi fa il conto: CrowdStrike parla di 1.413 CVE, altri di 1.411. La sostanza però è la stessa, perché è il rilascio più grande di sempre. Una settantina di falle sono classificate critiche. Due erano già pubbliche prima della correzione e una è già sfruttata negli attacchi.
Lo zero-day: il file non sembra più arrivare da fuori
La falla sfruttata è la CVE-2026-96951 e riguarda la Shell di Windows, cioè la parte del sistema che gestisce file, cartelle e collegamenti. Ha un punteggio di gravità di 8.8 su 10. Il bersaglio è il Mark of the Web, l'etichetta invisibile che Windows applica ai file scaricati da internet o arrivati via email. È quell'etichetta a far scattare SmartScreen e ad aprire i documenti Office in Visualizzazione protetta. Con questa falla l'etichetta sparisce: il file viene trattato come se fosse stato creato sul PC e non compare nessun avviso.
Serve comunque che l'utente apra qualcosa, per esempio un allegato costruito ad arte o un link. Non servono privilegi particolari. È lo scenario classico del phishing mirato, e funziona proprio perché salta l'ultimo cartello che dice «attenzione, questo file viene da fuori». Microsoft non ha detto chi la stia sfruttando né in che modo.
Tra le falle già rese pubbliche prima della patch c'è la CVE-2026-108398 in .NET Framework. Può permettere di aggirare WDAC (Windows Defender Application Control), lo strumento con cui molte aziende decidono quali programmi possono girare sui loro computer. L'altra è un denial of service, cioè un blocco del servizio, nella libreria MessagePack-CSharp. Per la maggior parte delle aziende è meno urgente.
Come mettere in fila il lavoro
Con un volume così, «installa tutto subito» non è un piano. Un ordine ragionevole è questo. Prima la correzione della Shell su tutte le postazioni degli utenti, perché è già usata negli attacchi e arriva dalla posta. Poi le falle critiche dei server esposti e dei servizi raggiungibili dalla rete. Poi tutto il resto, a ondate, dopo una prova su un piccolo gruppo di macchine. Nel frattempo conviene ricontrollare i filtri sugli allegati, come archivi, collegamenti .lnk e file ISO: riduce lo spazio in cui la falla può essere sfruttata.
Fonte: Cyber Security 360
La tua azienda è pronta ad affrontare una minaccia come questa?
Richiedi una valutazione gratuita →
Millequattrocento falle fanno impressione sulla carta, ma chi gestisce un'infrastruttura vera sa che contarle è la parte facile. Il difficile è tutto quello che c'è intorno al singolo aggiornamento. Su un server in produzione «installare la patch» vuol dire una catena di passaggi. Un orchestratore la mette in coda e il riavvio va programmato dentro la finestra di manutenzione concordata. Il monitoraggio va messo in pausa, per non svegliare mezzo reparto con allarmi finti, e la macchina va tolta dal bilanciatore prima che faccia cadere le sessioni degli utenti. Poi bisogna aspettare che torni su davvero e verificare che la patch risulti installata, non solo scaricata. Bisogna controllare che i servizi siano partiti tutti e nell'ordine giusto, rimettere il nodo nel pool e togliere la pausa al monitoraggio. Basta saltare uno di questi passi e il problema non è più la CVE. Diventa un nodo che sulla console sembra sano e intanto non risponde, oppure un monitoraggio rimasto zitto per tre giorni senza che nessuno se ne accorga. Mi è capitato più di una volta di trovare proprio questo.
Per lo zero-day della Shell, secondo me, il discorso è più semplice. Riguarda soprattutto le postazioni, dove un riavvio andato storto dà fastidio ma non ferma l'azienda. Sui server invece un rilascio di queste dimensioni mette alla prova proprio l'automazione. Chi oggi aggiorna ancora a mano rischia di passarci il mese intero: si collega in RDP a una macchina alla volta e spera di ricordarsi di riattivare gli allarmi. Non dico che l'orchestratore risolva tutto, perché va scritto, provato e mantenuto. Ammetto anche che non ho una risposta valida per ogni azienda sul compromesso tra velocità e prudenza per le falle critiche dei server esposti. Però un flusso ripetibile, con le verifiche dopo il riavvio e un modo pulito per tornare indietro, fa la differenza. È quello che separa un Patch Tuesday noioso da un fine settimana passato a capire perché il bilanciatore manda traffico a un nodo spento. Se vuoi impostare o rivedere la catena che porta una patch dal rilascio fino al server riavviato e rimesso in servizio, possiamo disegnarla insieme sui sistemi che hai già.