YellowKey (CVE-2026-45585): la vulnerabilità che nessuna scansione trova

Un portatile aziendale cifrato con BitLocker viene rubato in aeroporto. Fino a maggio 2026 la risposta era ragionevolmente tranquilla: il disco è cifrato, i dati sono inaccessibili, l’incidente è la perdita dell’hardware.

Poi è comparsa YellowKey, e quella tranquillità va ricalcolata.

CVE-2026-45585 è un bypass delle protezioni di BitLocker che sfrutta il comportamento del Windows Recovery Environment. L’Agenzia per la Cybersicurezza Nazionale la descrive come un’anomalia nel flusso di avvio dell’ambiente di ripristino, inducibile manipolando componenti usati durante quel processo, che porta all’apertura di una console con privilegi elevati in un contesto dove il volume protetto risulta già sbloccato.

Il punto che rende questa vulnerabilità interessante oltre il caso specifico è un altro: nessuna scansione della vostra rete l’avrebbe mai trovata. Non è raggiungibile da un indirizzo IP. Si raggiunge avendo il dispositivo in mano.

1. Cosa colpisce e cosa no
2. Perché “gravità media” è fuorviante
3. Il calcolo che cambia sul laptop rubato
4. Il PoC pubblicato senza coordinamento
5. Cosa verificare sui vostri dispositivi
6. La categoria di vulnerabilità che le scansioni non vedono

Cosa colpisce e cosa no

Una precisazione che conta e che spesso viene persa nei titoli: il rischio non è che l’algoritmo di cifratura di BitLocker sia stato violato pubblicamente, ma che un attaccante fisicamente presente possa abusare del comportamento dell’ambiente di ripristino per raggiungere dati che BitLocker doveva proteggere a riposo. L’algoritmo tiene. È la catena di fiducia attorno a esso che cede.

Il funzionamento di BitLocker e il ruolo del TPM sono descritti nell’articolo su funzionalità e vantaggi di BitLocker; qui interessa il punto in cui quella catena si interrompe.

Perché “gravità media” è fuorviante

Il punteggio 6.8 collocherebbe questa vulnerabilità fra quelle da sistemare durante la normale manutenzione. Il numero è basso per una ragione precisa: il vettore richiede accesso fisico, e il calcolo CVSS penalizza pesantemente questa condizione.

È corretto come metrica generale, e ingannevole nel vostro caso specifico. Perché BitLocker esiste in gran parte per proteggere i dati quando un portatile viene perso, rubato, lasciato incustodito, spedito, riparato o dismesso: tutte situazioni in cui l’accesso fisico non è un ostacolo, è il presupposto.

Una vulnerabilità che richiede accesso fisico è irrilevante su un server in datacenter. È molto rilevante su un portatile che viaggia, su una postazione in area accessibile, su un dispositivo in riparazione presso terzi. È l’esempio più chiaro di quanto un punteggio di gravità vada riletto sul contesto — il ragionamento è quello descritto in CVSS, EPSS e CISA KEV.

Il calcolo che cambia sul laptop rubato

Qui sta la conseguenza che riguarda direttamente chi in azienda deve decidere, e che nei bollettini tecnici non compare.

Quando un dispositivo aziendale viene rubato, la valutazione sulla notifica agli interessati prevista dal GDPR dipende in modo determinante dallo stato dei dati. Un disco cifrato con una misura efficace rende i dati inintelligibili a chi non è autorizzato, e questo pesa sulla valutazione del rischio per i diritti delle persone coinvolte.

YellowKey non annulla quel ragionamento, ma introduce una variabile che prima non c’era: se il dispositivo rubato era su una build interessata e senza le mitigazioni applicate, la cifratura potrebbe non aver protetto nulla. Il che significa che la valutazione da fare in caso di furto ora richiede una domanda in più — quel dispositivo era aggiornato? — e che la risposta va documentata prima, non ricostruita dopo.

Vale lo stesso per gli obblighi introdotti dalla direttiva NIS2 sulle valutazioni tracciabili, e per la dismissione dei dispositivi, dove la cancellazione crittografica descritta nell’articolo su come eliminare i dati in modo definitivo poggia sulle stesse assunzioni.

Il PoC pubblicato senza coordinamento

Un dettaglio di questa vicenda merita attenzione perché è la parte più insolita. Microsoft ha dichiarato che il proof of concept è stato reso pubblico in violazione delle buone pratiche di divulgazione coordinata, e ha emesso il CVE proprio per fornire indicazioni di mitigazione in attesa dell’aggiornamento di sicurezza.

Tradotto in termini operativi: per un intervallo di tempo il codice dimostrativo era pubblicamente disponibile e la correzione no. È lo scenario che la divulgazione coordinata delle vulnerabilità serve a evitare, e la ragione per cui esiste quella prassi.

Per voi la conseguenza è pratica: le finestre fra divulgazione e patch non sono un’astrazione, e in quei giorni le mitigazioni pubblicate dal produttore sono l’unica cosa disponibile. Sono anche il periodo in cui le indicazioni ufficiali vanno lette, non aspettate — che è un comportamento diverso dall’attendere il ciclo di aggiornamento ordinario.

Cosa verificare sui vostri dispositivi

Le indicazioni operative sono quelle del produttore, e la prima è l’applicazione degli aggiornamenti: la correzione è stata distribuita nel ciclo di aggiornamenti di giugno 2026. Le verifiche che vale la pena fare attorno a quella sono quattro.

Quali dispositivi sono su build interessate, distinguendo fra parco aggiornato e dispositivi che non si collegano da mesi — i portatili di chi lavora prevalentemente fuori sede sono la categoria a rischio. Quali dispositivi contengono dati che, in caso di accesso, farebbero scattare obblighi di notifica. Come è configurata l’autenticazione all’avvio: la presenza di un fattore aggiuntivo oltre al TPM cambia il quadro. E infine chi ha accesso fisico ai dispositivi lungo il loro ciclo di vita, inclusi i fornitori che li assistono o li smaltiscono.

L’ultima è quella che le aziende trascurano di più, e riguarda un perimetro che non è vostro ma vi riguarda: il dispositivo in riparazione è fuori dal vostro controllo e dentro il vostro rischio.

La categoria di vulnerabilità che le scansioni non vedono

Torniamo al punto da cui siamo partiti, perché è quello che vale oltre YellowKey.

Una scansione delle vulnerabilità interroga sistemi raggiungibili via rete. È efficace su ciò che risponde a un indirizzo, e strutturalmente cieca su tutto il resto. Una vulnerabilità che si sfrutta avendo il dispositivo in mano non compare in nessun report di scansione, per la ragione elementare che non c’è niente da interrogare.

Nella stessa categoria ricadono l’accesso a postazioni non presidiate, i dispositivi collegati fisicamente alla rete in aree accessibili, i punti di rete attivi in sale riunioni e reception, i supporti rimovibili. Sono vettori reali, con impatto misurabile, che non esistono per nessuno strumento automatico.

L’unica verifica che li copre è un test condotto con un perimetro che li includa. Ed è qui che la differenza fra vulnerability assessment e penetration test diventa concreta: la prima misura ciò che è raggiungibile dalla rete, il secondo verifica cosa si ottiene partendo da un punto d’ingresso definito — e quel punto d’ingresso può essere una scrivania.

Vale la pena chiederlo quando si definisce l’ambito di un penetration test: se il perimetro è descritto solo da indirizzi IP, tutta questa categoria resta fuori dal report, e non perché non ci sia.