Microsoft ha scelto una linea durissima contro la pubblicazione non coordinata di exploit e proof-of-concept relativi a vulnerabilità presenti in Windows e negli altri software supportati. La decisione arriva dopo settimane particolarmente complicate per il gruppo di Redmond: diversi zero-day sono comparsi online prima della distribuzione di una patch ufficiale, alcuni dei quali hanno trovato rapidamente applicazione in attacchi reali.
Tra gennaio e aprile 2026 l’azienda ha corretto decine di vulnerabilità critiche, inclusi numerosi zero-day sfruttati attivamente. Alcuni report indipendenti hanno evidenziato come le falle di tipo Elevation of Privilege rappresentino ormai oltre la metà delle vulnerabilità corrette nei bollettini mensili di sicurezza Microsoft. In pratica, una volta ottenuto un accesso iniziale a un sistema, gli aggressori dispongono sempre più spesso di strumenti per acquisire privilegi amministrativi o addirittura diritti SYSTEM.
La reazione del Microsoft Security Response Center
Attraverso un comunicato ufficiale, il Microsoft Security Response Center (MSRC) ha criticato apertamente la diffusione pubblica di exploit relativi a vulnerabilità ancora prive di aggiornamenti correttivi. Secondo Microsoft, la pubblicazione di codice funzionante prima della disponibilità di una patch correttiva espone utenti e aziende a rischi concreti, riducendo drasticamente il tempo disponibile per preparare contromisure efficaci.
Il messaggio più discusso riguarda però il passaggio dedicato alle possibili conseguenze legali. Microsoft ha dichiarato di essere pronta a collaborare con le forze dell’ordine e ad avviare azioni giudiziarie contro chi favorisce attività criminali attraverso la diffusione irresponsabile di exploit.
Una formulazione volutamente ampia che molti osservatori hanno interpretato come un avvertimento rivolto non soltanto agli attaccanti ma anche a chi pubblica materiale tecnico relativo agli zero-day.
Il caso Nightmare Eclipse e la serie di zero-day pubblicati
Al centro della controversia compare il ricercatore conosciuto con gli pseudonimi Nightmare Eclipse o Chaotic Eclipse. Nel giro di poche settimane, ha pubblicato dettagli tecnici e codice per lo sfruttamento di almeno 6 vulnerabilità Windows, creando un caso che ha rapidamente attirato l’attenzione dell’intero settore.
Tra le vulnerabilità delle quali si è ampiamente parlato figurano BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091), UnDefend (CVE-2026-45498) e YellowKey (CVE-2026-45585). Alcune di queste consentono l’acquisizione di privilegi elevati fino al livello SYSTEM, mentre altre compromettono componenti di protezione come Microsoft Defender o tecnologie di sicurezza come BitLocker.
Secondo varie analisi indipendenti, le vulnerabilità BlueHammer, RedSun, UnDefend e YellowKey risultano già sfruttate in attacchi reali. Microsoft ha di recente provato ad arginare la disabilitazione forzata di BitLocker descrivendo gli interventi difensivi applicabili in attesa di una patch.
Le accuse reciproche sulla divulgazione responsabile
La questione non riguarda soltanto gli aspetti tecnici. Nightmare Eclipse sostiene infatti di aver tentato in passato di segnalare vulnerabilità attraverso i canali ufficiali del programma Microsoft. Secondo la sua versione dei fatti, l’account utilizzato per interagire con il MSRC sarebbe stato prima bloccato e successivamente eliminato senza spiegazioni adeguate.
Microsoft non ha fornito dettagli pubblici sulla vicenda, ma ha ribadito l’importanza delle procedure di Coordinated Vulnerability Disclosure, il modello adottato dalla maggior parte dell’industria. Il ricercatore segnala privatamente il problema, il produttore sviluppa una correzione e soltanto successivamente sono diffusi i dettagli tecnici. Il meccanismo funziona bene quando entrambe le parti collaborano. Quando il rapporto si deteriora, però, emergono situazioni come quella attuale.
Va detto però che la comunità della sicurezza osserva con attenzione anche il comportamento dei vendor. Diversi professionisti ricordano che minacce legali contro i ricercatori possono produrre l’effetto opposto rispetto a quello desiderato: meno segnalazioni, minore collaborazione e una crescente tendenza a pubblicare direttamente le vulnerabilità. Tant’è vero che dopo il ban, voluto da Microsoft, sia da GitHub che da GitHub, Nightmare Eclipse ha pubblicato il numero “7” sul suo blog, a lasciare intendere di avere già “in caldo” la settima vulnerabilità zero-day che interessa i sistemi Windows.
Le critiche al programma MSRC
La reputazione del MSRC è stata spesso considerata positiva nel settore. Negli ultimi mesi, tuttavia, sono emerse critiche sempre più frequenti: il ricercatore Will Dormann ha sostenuto pubblicamente che Microsoft avrebbe ridimensionato alcune competenze interne, sostituendo figure molto esperte con procedure più burocratiche e standardizzate. Le dichiarazioni hanno alimentato un dibattito acceso, soprattutto dopo l’emergere di requisiti operativi ritenuti discutibili da alcuni ricercatori.
Tra le contestazioni più citate compare la presunta richiesta di allegare video dimostrativi degli exploit durante la segnalazione delle vulnerabilità. Diversi osservatori ritengono che un simile requisito possa rallentare il processo di reporting, specialmente per chi svolge ricerca indipendente.
Microsoft non ha ancora chiarito pubblicamente se tale procedura rappresenti effettivamente un requisito obbligatorio per tutti i casi.
Dopo la pubblicazione del post ufficiale MSRC contenente le minacce legali, numerosi ricercatori hanno condiviso esperienze personali che mettono in discussione l’efficacia e la trasparenza del processo di Coordinated Vulnerability Disclosure adottato dall’azienda.
Tra questi figura Gabriel Landau, noto esperto di sicurezza Windows, che ha raccontato di aver segnalato un bypass di Device Guard concedendo inizialmente 90 giorni per la correzione. Secondo il suo resoconto, MSRC avrebbe riconosciuto la validità del problema e richiesto ulteriore tempo prima della divulgazione pubblica, promettendo l’assegnazione di un identificativo CVE. Dopo la distribuzione della patch, tuttavia, Microsoft avrebbe cambiato valutazione sostenendo che la vulnerabilità non soddisfaceva i criteri necessari per ottenere un CVE, pubblicando la correzione senza alcun riconoscimento ufficiale.
Anche il ricercatore noto come rootsecdev ha riferito un’esperienza analoga: una vulnerabilità legata ai meccanismi di autenticazione legacy, che consentiva attività di password spraying aggirando Smart Lockout, sarebbe stata corretta in modo silenzioso dopo diversi mesi, per poi essere classificata da Microsoft come non sufficientemente rilevante per un intervento di sicurezza ufficiale.
Una frattura che rischia di danneggiare tutti
Lo scontro tra Microsoft e Nightmare Eclipse evidenzia un problema più ampio che interessa l’intero settore della sicurezza informatica.
Le aziende hanno bisogno dei ricercatori indipendenti per individuare vulnerabilità prima degli attaccanti. I ricercatori, a loro volta, hanno bisogno di programmi di Bug Bounty efficienti, interlocutori tecnici competenti e procedure rapide. Programmi Bug Bounty che noi vorremmo fossero estesi anche alla Pubblica Amministrazione italiana, proprio per evitare la diffusione silenziosa di exploit.
Le minacce legali possono allontanare chi scopre vulnerabilità in buona fede; la pubblicazione incontrollata di exploit può esporre milioni di utenti a compromissioni immediate. Trovare un equilibrio resta difficile, soprattutto in un periodo in cui gli zero-day continuano ad aumentare e il tempo necessario per trasformarli in armi operative si riduce ogni mese.
Tuttavia, spiace osservare che quello che nelle intenzioni di Microsoft doveva essere un chiarimento a difesa delle proprie procedure si è trasformato, almeno in parte, in un’occasione per molti ricercatori di raccontare episodi che hanno contribuito a erodere la fiducia nei confronti del processo di gestione delle vulnerabilità adottato dall’azienda.
Microsoft, inoltre, ha eliminato l’account GitHub/GitLab associato a Nightmare Eclipse, ma copie degli exploit erano già state replicate altrove. Una volta che il codice entra nei circuiti della ricerca offensiva, riportarlo sotto controllo diventa quasi impossibile.
A questo punto, sarebbe davvero opportuno fermare tutto, riaprire le porte del dialogo e promuovere iniziative tese a riacquisire la fiducia e la collaborazione dei ricercatori che intendono agire in maniera responsabile.