Microsoft Defender, nuovo zero-day ShieldCrash buca anche la patch di settembre

Puntuale come una falla zero-day nel giorno sbagliato, il ricercatore di sicurezza conosciuto come Nightmare Eclipse ha pubblicato i dettagli circa l’ennesima vulnerabilità irrisolta in Windows e, in particolare, in Microsoft Defender. Per farlo, vista la sfida che ha lanciato nei confronti di Microsoft ormai diversi mesi fa, Nightmare Eclipse ha aspettato lo “scoccare” del Patch Tuesday di settembre 2026 e, dopo l’avvenuta pubblicazione degli aggiornamenti ufficiali, ha voluto sferrare la sua nuova staffilata contro gli ingegneri e i tecnici di Redmond.

ShieldCrash è il nome scelto per il nuovo proof-of-concept (PoC) che riesce a sfruttare una variante del problema già corretto da Microsoft come CVE-2026-69414, vulnerabilità battezzata ShieldBreak. Il lavoro svolto da Nightmare Eclipse è importante soprattutto perché il PoC funziona anche sui sistemi Windows completamente aggiornati.

Da RoguePlanet a ShieldCrash: perché le patch continuano a essere aggirate

La vicenda non nasce a settembre. Parte almeno da giugno 2026 con RoguePlanet, prosegue con la correzione distribuita da Microsoft a luglio, continua ad agosto con ShieldBreak e arriva ora a ShieldCrash.

RoguePlanet, identificata successivamente come CVE-2026-50656, sfruttava una race condition durante le operazioni di quarantena di Microsoft Defender. L’exploit manipolava file e dischi virtuali cercando di modificare ciò che Defender vedeva e utilizzava tra un controllo e l’operazione successiva. Il risultato poteva portare alla sovrascrittura di file protetti e infine all’esecuzione di una shell con privilegi SYSTEM.

Una race condition nasce quando il risultato di un’operazione dipende dall’ordine e dalla tempistica con cui più attività accedono alle stesse risorse.

Microsoft è intervenuta a luglio 2026 con un primo aggiornamento per il motore di Defender ma poco più di un mese dopo Nightmare Eclipse ha svelato ShieldBreak sostenendo di aver trovato un percorso alternativo capace di ottenere nuovamente un’elevazione dei privilegi.

ShieldBreak non riproduceva semplicemente la race condition di RoguePlanet. L’exploit sfruttava callback in modalità utente per alterare il contenuto di un file durante un’operazione di scansione legata alla Cloud Files API.

Che cosa aveva corretto Microsoft con CVE-2026-69414

Microsoft ha associato ShieldBreak alla vulnerabilità CVE-2026-69414: non parliamo di una vulnerabilità sfruttabile direttamente da Internet contro un PC semplicemente acceso e connesso. Un aggressore deve prima riuscire a eseguire codice in locale con un account o un processo dotato di privilegi limitati. È però proprio questo lo scenario nel quale le vulnerabilità di privilege escalation diventano preziose durante un attacco reale: malware, infostealer o aggressori che hanno già ottenuto un primo punto d’appoggio possono tentare di passare da un ambiente confinato ai diritti SYSTEM.

ShieldCrash riesce a superare anche la correzione di settembre

Secondo Nightmare Eclipse, la nuova falla ShieldCrash dimostra che la correzione di ShieldBreak non copre tutti i casi.

Il ricercatore afferma che Microsoft abbia modificato diversi punti del codice per impedire nuovi sfruttamenti, lasciando però disponibile almeno un percorso attraverso il quale si può ancora innescare lo stesso problema di fondo.

Il repository pubblico su GitHub allestito da Nightmare Eclipse contiene il codice che dimostra le asserzioni del ricercatore. Ad essere interessate sarebbero tutte le versioni supportate di Windows, compresi Windows 10, Windows 11 e Windows Server.

La dimostrazione pubblicata il 9 settembre offre per ora una primitiva di lettura privilegiata ma il ricercatore ha puntualizzato di poter eventualmente trasformare lo scheletro attuale in un PoC con capacità SYSTEM più complete.

Il ruolo particolare di Defender rende serie queste vulnerabilità

Un antivirus deve necessariamente fare cose che un normale processo non può fare. Deve aprire file appartenenti a utenti differenti, osservare processi, intervenire su elementi sospetti, spostare oggetti in quarantena e accedere a parti sensibili del sistema. Molte di queste attività richiedono privilegi elevati.

Nasce così una situazione quasi paradossale: il software progettato per proteggere il PC dispone proprio delle autorizzazioni che rendono particolarmente interessante un errore nel modo in cui il software gestisce dati controllabili da processi sprovvisti di diritti più ampi.

Qualunque soluzione endpoint profondamente integrata con Windows espone una superficie simile. Antivirus, EDR, agenti di gestione e strumenti di backup possiedono spesso servizi SYSTEM, driver kernel o componenti capaci di manipolare file protetti. Per questo la validazione dei percorsi, la gestione degli handle e l’immutabilità degli oggetti tra controllo e utilizzo diventano aspetti critici.

Una disputa sulla condivisione dei dettagli tecnici che ormai ha conseguenze tecniche concrete

ShieldCrash si inserisce in una vicenda più ampia. Da aprile 2026 Nightmare Eclipse ha pubblicato numerosi exploit riguardanti Defender, BitLocker e altri componenti Windows, tra cui RoguePlanet, ShieldBreak, LegacyHive, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma e UnDefend.

Microsoft ha criticato duramente la pubblicazione non coordinata di vulnerabilità ancora prive di patch. In un intervento del 27 maggio 2026, il Microsoft Security Response Center (MSRC) ha ricordato che la Coordinated Vulnerability Disclosure offre al produttore il tempo necessario per analizzare il problema e proteggere i clienti prima della diffusione di exploit funzionanti; l’azienda ha anche evocato possibili azioni legali nei confronti di soggetti le cui attività potessero provocare danni reali.

La ricostruzione di Nightmare Eclipse è però differente. Il ricercatore sostiene di aver utilizzato in passato i normali canali MSRC, lamentando segnalazioni ignorate o gestite in modo insoddisfacente, mancati riconoscimenti economici e, infine, la revoca dell’accesso all’account Microsoft impiegato per inviare i report.

Proprio da queste precedenti esperienze, secondo la sua versione, sarebbe nata la decisione di abbandonare la disclosure coordinata e pubblicare direttamente exploit e dettagli tecnici.