C'è un presupposto su cui si regge la sicurezza di quasi ogni PC moderno: il Secure Boot, il meccanismo UEFI che impedisce l'esecuzione di codice non firmato durante l'avvio. Una ricerca pubblicata il 14 luglio da ESET dimostra che questo presupposto era, fino a poche settimane fa, molto più fragile del previsto: 11 vecchi bootloader firmati da Microsoft, dimenticati da tutti ma ancora considerati affidabili, permettevano di aggirare il Secure Boot sulla stragrande maggioranza dei sistemi in circolazione, Windows e Linux indifferentemente.

Cosa è successo

Il ricercatore Martin Smolár di ESET ha individuato 11 shim UEFI — i piccoli bootloader di prima fase che Microsoft firma per conto di terze parti, tipicamente distribuzioni Linux e strumenti diagnostici — in versioni 0.9 o precedenti, tutti firmati con il certificato Microsoft Corporation UEFI CA 2011. Al caso sono stati assegnati due identificativi, CVE-2026-8863 e CVE-2026-10797. La segnalazione è arrivata al CERT/CC a febbraio 2026 e i binari vulnerabili sono stati revocati con l'aggiornamento del database dbx distribuito nel Patch Tuesday del 9 giugno; la pubblicazione dei dettagli tecnici è di questa settimana.

Il punto cruciale è che non serve avere installato il software incriminato: qualsiasi macchina che consideri affidabile il certificato UEFI di terze parti di Microsoft — cioè quasi tutte, con l'eccezione dei PC Secured-core dove è disattivato di default — può essere attaccata portando una copia dello shim vulnerabile sulla partizione EFI. Una tecnica "bring your own bootloader", concettualmente identica al "bring your own vulnerable driver" che da anni affligge Windows.

La parte più istruttiva della ricerca è la semplicità dello sfruttamento. Gli shim datati trascinano con sé bootloader di seconda fase altrettanto datati, in gran parte vecchie versioni di GRUB 2 con vulnerabilità note da anni. Nel proof of concept, ESET usa lo shim di Oracle Linux 7.1 e un GRUB 2 affetto dalla CVE-2015-5281: il comando multiboot2, che carica codice non firmato per progetto, è sufficiente a eseguire un binario arbitrario all'avvio. Niente memory corruption, niente exploit sofisticati: basta una copia di un binario vecchio di dieci anni, firmato e mai revocato. Gli shim precedenti alla versione 0.9, inoltre, ignorano i meccanismi di revoca introdotti successivamente, come SBAT e la lista di blocco MokListX: montarli equivale a riportare indietro l'orologio della sicurezza di avvio di un decennio.

Perché è grave

Aggirare il Secure Boot significa poter installare un bootkit UEFI: malware che si carica prima del sistema operativo e di qualsiasi antivirus o EDR, sopravvive alla reinstallazione del sistema e resta invisibile alla gran parte degli strumenti di difesa. Non è teoria: BlackLotus, HybridPetya e Bootkitty hanno dimostrato che i bootkit sono ormai parte dell'arsenale reale degli attaccanti. Va detto con chiarezza: per scrivere sulla partizione EFI servono privilegi amministrativi o accesso fisico alla macchina. Questa non è una falla di accesso iniziale, ma una tecnica di persistenza post-compromissione — ed è proprio questo il suo valore per un attaccante: trasformare una compromissione qualsiasi in una presenza che nessuna bonifica ordinaria rimuove.

C'è poi un problema strutturale che la ricerca mette a nudo: il processo di firma degli shim è diventato trasparente solo nel 2017. Di quelli firmati prima non esiste un catalogo completo: nessuno può dire quanti altri binari dimenticati e ancora affidabili circolino. Gli 11 shim revocati riducono la superficie, ma non la azzerano.

Cosa significa per le aziende italiane

Nella pratica di molte organizzazioni italiane — PA, sanità, manifattura — gli aggiornamenti del database di revoca dbx sono storicamente trattati con prudenza, per il timore di rendere non avviabili sistemi dual-boot o appliance particolari. Il risultato è che flotte intere restano con revoche vecchie di anni: su quelle macchine gli 11 shim sono ancora perfettamente validi. La lezione di questa ricerca è che il dbx va gestito come qualsiasi altra patch di sicurezza, con test e rollout, non rimandato a tempo indeterminato.

Il rischio concreto riguarda soprattutto gli ambienti dove la compromissione di un endpoint ha conseguenze durature: postazioni operative in produzione, sistemi di controllo, notebook di dirigenti e amministratori. In un contesto NIS2, la capacità di garantire l'integrità della catena di avvio rientra a pieno titolo tra le misure di protezione dei sistemi richieste ai soggetti essenziali e importanti.

Cosa fare subito

  • Verificare che gli aggiornamenti cumulativi di giugno 2026 (che includono la revoca dbx) siano effettivamente installati su tutto il parco Windows.
  • Controllare lo stato delle revoche: su Windows si può interrogare il dbx via PowerShell con Get-SecureBootUEFI confrontando gli hash pubblicati da ESET; su Linux gli aggiornamenti arrivano tramite fwupd/LVFS.
  • Sui dispositivi che lo supportano, valutare la disattivazione del certificato UEFI di terze parti (opzione Secured-core / Microsoft third-party CA) dove non servono bootloader non Microsoft.
  • Configurare l'EDR per segnalare scritture anomale sulla partizione EFI di sistema, un indicatore precoce di tentativi di persistenza a livello boot.
  • Includere la verifica dell'integrità di avvio (Measured Boot, attestazione remota dove disponibile) nelle attività di incident response: dopo una compromissione con privilegi amministrativi, la partizione EFI va considerata sospetta.

La morale è quella che i ricercatori stessi suggeriscono: ciò che non è stato catalogato in modo trasparente non può essere revocato in modo efficace. Nel frattempo, l'unica difesa concreta è tenere aggiornato anche quel pezzo di sicurezza — il firmware e le sue liste di revoca — che quasi nessun piano di patch management oggi considera.