ESET ha identificato 11 vecchi bootloader UEFI shim, versione 0.9 o precedente, che per anni hanno permesso il bypass di Secure Boot su qualsiasi sistema che trusta il certificato Microsoft Corporation UEFI CA 2011. La revoca è arrivata il 9 giugno 2026 con la Patch Tuesday Microsoft, coordinata da CERT/CC a partire dalla segnalazione del ricercatore Martin Smolár del 16 febbraio 2026.
La scadenza dello stesso certificato, il 27 giugno 2026, non risolve il problema: finché un binario firmato non entra nel dbx per hash specifico, resta tecnicamente trusted indipendentemente dalla data di scadenza del certificato.
- ESET ha identificato 11 shim UEFI firmati da Microsoft, appartenenti a 10 vendor diversi, che permettono il bypass di Secure Boot indipendentemente dal sistema operativo installato.
- Il meccanismo non richiede vulnerabilità zero-day: gli shim pre-0.9 ignorano la MOK denylist e quelli pre-15.3 ignorano la revoca SBAT, consentendo il caricamento di bootloader non autorizzati.
- Microsoft ha assegnato CVE-2026-8863 con punteggio CVSS:3.1 7.8 secondo il proprio Security Update Guide.
- Il certificato Microsoft UEFI CA 2011, scaduto il 27 giugno 2026, non blocca automaticamente i binari già firmati: la verifica Secure Boot non controlla la data di scadenza del certificato nel db.
Il meccanismo: due letture diverse della stessa firma
Il cuore della vulnerabilità documentata come CVE-2026-10797 è un mismatch nella lettura della lunghezza della firma PE. Un binario firmato registra la dimensione della firma in due punti distinti del header; gli shim affetti leggono una posizione durante il revocation check e l'altra durante la signature verification.
Manipolando la struttura WIN_CERTIFICATE, un attaccante indirizza il controllo di revoca verso byte sbagliati, facendo passare un binario revocato come valido. Questo errore era stato corretto upstream quasi un decennio fa, ma i vecchi shim firmati da Microsoft non erano stati revocati nel dbx.
La MOK denylist enforcement è arrivata solo con shim 0.9; il supporto SBAT solo con la 15.3. Shim compilati prima di queste soglie ignorano le revoche corrispondenti, lasciando un varco strutturale nel controllo di integrità del boot.
"What makes these old shims dangerous is not a novel vulnerability, it's that no new vulnerability is needed to bypass UEFI Secure Boot" — ESET
Undici hash nel dbx, ma l'incertezza resta
ESET ha pubblicato l'elenco completo dei 11 hash SHA256 PE Authenticode, confermato anche nell'advisory CERT/CC VU#616257. I shim interessati appartengono a Spyrus, RedHat, CentOS, baramundi, WhiteCanyon/Blancco, Finland's Matriculation Examination Board, NTC IT ROSA, Oracle, PC-Doctor e OpenSuse.
Ogni sistema UEFI con il certificato Microsoft Corporation UEFI CA 2011 nel db è affetto, "regardless of the installed operating system", come documenta ESET nel blog ufficiale. Non è richiesto che il sistema operativo originale del vendor sia presente.
Secondo Help Net Security / ESET analysis, "no one can say with confidence how many old, still-trusted shims remain". La fonte non specifica quanti altri shim pre-2017 restino non identificati e non revocati, lasciando aperta la questione della completezza della mitigazione.
La revoca è avvenuta il 9 giugno 2026 durante la Patch Tuesday Microsoft. Il coordinamento CERT/CC era iniziato il 16 febbraio 2026, giorno della segnalazione iniziale di Martin Smolár. L'intervallo di quattro mesi tra segnalazione e rilascio riflette la complessità del processo di revoca distribuita su milioni di sistemi.
Attacco BYOVD: porti il tuo bootloader vulnerabile
L'exploitation segue un pattern Bring Your Own Vulnerable Driver trasposto al firmware: l'attaccante copia sul sistema target il proprio shim vulnerabile, abbinato a un second-stage loader compatibile. Help Net Security cita come esempio storico CVE-2015-5281 per Oracle Linux shim, ma il principio si applica a qualsiasi bootloader che lo shim caricato accetti.
Il risultato è persistenza pre-OS che sopravvive a reinstallazioni del sistema operativo. I privilegi richiesti sono locali e amministrativi. Microsoft MSRC classifica CVE-2026-8863 con CVSS:3.1 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), severity Important, con assessment "Exploitation Less Likely" e stato "Exploited: No".
Martin Smolár, ricercatore ESET, ha dichiarato: "An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware".
Cosa fare adesso
Le azioni prioritarie derivano dalle raccomandazioni enterprise documentate da CERT/CC:
- Applicare l'update dbx della Patch Tuesday del 9 giugno 2026 attraverso i canali di aggiornamento del vendor di sistema o del sistema operativo.
- Verificare che i sistemi enterprise ricevano gli aggiornamenti firmware distribuiti tramite i programmi di gestione patch del vendor.
- Monitorare gli advisory dei vendor interessati per eventuali aggiornamenti specifici del bootloader o del firmware.
La fonte non specifica procedure tecniche di verifica manuale, né raccomanda la disabilitazione del third-party UEFI CA signing come mitigazione standard. L'update dbx è il veicolo corretto per la revoca.
Perché è importante
Il caso mette in luce un deficit strutturale nella governance dei certificati UEFI: Microsoft ha firmato componenti per anni, e il repository shim-review esiste dal 2017. Il certificato CA 2011, scaduto il 27 giugno 2026, resta nel db di milioni di sistemi perché la scadenza non attiva alcuna invalidazione automatica.
La revoca per hash nel dbx è l'unico meccanismo efficace, ma richiede che qualcuno identifichi sistematicamente i binari vulnerabili. Fino al 2026, 11 shim firmati erano rimasti attivi nonostante vulnerabilità note da quasi un decennio.
La fonte non specifica se Windows 11 Secured-core PCs abbiano effettivamente third-party signing disabilitato come previsto. Non specifica inoltre quanti sistemi Linux non abbiano ancora applicato l'update dbx, né se l'exploitation sia già avvenuta in-the-wild.
Il problema resta aperto per qualsiasi altro shim pre-2017 non ancora catalogato: la fiducia nel Secure Boot dipende dalla completezza del dbx, non dalla presenza di vulnerabilità zero-day.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/07/11-old-microsoft-signed-linux-uefi.html
- https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/
- https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/
- https://www.kb.cert.org/vuls/id/616257
- https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-8863
- https://pluang.com/en/news-feed/eset-temukan-kerentanan-uefi-shim-bahayakan-boot-aman-perangkat
- https://research.checkpoint.com/2026/browser-only-ransomware-from-llm-hallucinations-to-a-practical-attack-technique/
- https://nvd.nist.gov/vuln/detail/CVE-2015-5281