Undici vecchi componenti di avvio Linux, ancora firmati e quindi considerati affidabili da molti PC, possono essere usati per aggirare Secure Boot. In pratica, un attaccante che riesce a intervenire nella fase di boot può far partire codice malevolo prima del sistema operativo, aprendo la strada a bootkit UEFI molto difficili da rilevare e rimuovere.
La notizia riguarda anche le aziende che non usano Linux sui desktop: il problema tocca i sistemi UEFI che si fidano del certificato Microsoft usato per avviare componenti di terze parti. Questo significa che il rischio dipende dal firmware e dalla catena di avvio, non solo dal sistema operativo che l’utente vede ogni giorno.
Che cosa è stato scoperto
Il 14 luglio 2026 The Hacker News ha riportato una ricerca di ESET, firmata da Martin Smolár, su 11 applicazioni UEFI obsolete ma ancora firmate da Microsoft che possono essere sfruttate per bypassare Secure Boot.
Il punto chiave è questo: molti dispositivi UEFI si fidano del certificato Microsoft Corporation UEFI CA 2011, usato per firmare componenti di boot di terze parti. Anche se questo certificato è scaduto il 27 giugno 2026 ed è stato sostituito da Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023, la fiducia nei componenti già firmati ha creato una finestra di rischio concreta.
Secondo ESET, un attaccante che sfrutta uno di questi componenti vulnerabili può eseguire codice non affidabile durante l’avvio del sistema. È una fase delicatissima: avviene prima che il sistema operativo sia inizializzato e prima che antivirus, EDR e altri strumenti di sicurezza possano intervenire.
Perché Secure Boot è importante
Secure Boot è una funzione di sicurezza del firmware UEFI pensata per consentire l’avvio solo di componenti firmati e ritenuti affidabili. In teoria, serve a impedire che malware o bootloader alterati prendano il controllo del PC nelle primissime fasi di accensione.
Nel mondo Linux, un ruolo centrale è svolto dallo shim, un piccolo bootloader open source che fa da intermediario tra il firmware della scheda madre e il sistema operativo. Il suo compito è permettere l’avvio di distribuzioni Linux anche quando Secure Boot è attivo.
La catena di fiducia, semplificando, funziona così:
- il firmware UEFI carica lo shim e ne verifica la firma tramite il certificato Microsoft presente nel dispositivo;
- lo shim verifica il bootloader di secondo livello, spesso GRUB2, usando un certificato del produttore o della distribuzione;
- GRUB2 verifica il kernel.
Il problema nasce quando uno shim vecchio, ancora firmato e quindi “accettato”, contiene debolezze che consentono di eludere i controlli successivi.
Come funziona l’aggiramento
La ricerca evidenzia un rischio tipico delle filiere software lunghe: anche se il progetto principale viene corretto, copie vecchie e vulnerabili possono continuare a circolare in prodotti di terze parti e restare valide dal punto di vista della firma.
In questo caso, bootloader shim molto datati — principalmente dalla versione 0.9 in giù — possono essere utilizzati per eseguire codice arbitrario all’avvio. Questo permette di installare bootkit UEFI come Bootkitty, HybridPetya o BlackLotus, anche con Secure Boot attivo.
L’attacco può inoltre richiamare un concetto già noto in sicurezza: BYOVD, cioè “bring your own vulnerable driver”. Qui il principio viene adattato alla fase di boot: l’attaccante porta con sé un componente vulnerabile ma firmato e lo usa per aggirare protezioni più recenti.
Un altro aspetto critico riguarda il meccanismo MOK (Machine Owner Key), che su Linux consente di autorizzare il caricamento di driver non firmati anche con Secure Boot abilitato. Sebbene lo shim 0.9 abbia introdotto una denylist per revocare certificati vecchi e vulnerabili, secondo ESET un aggressore potrebbe sostituire uno shim aggiornato con uno più vecchio firmato da Microsoft e sfruttare il fatto che la allowlist continui a fidarsi del certificato precedente.
In questo modo si potrebbe caricare senza restrizioni un binario vulnerabile e ottenere esecuzione di codice arbitrario.
Perché il problema è più ampio di un singolo software
La parte più interessante, e preoccupante, è che non si tratta di un bug confinato a una sola distribuzione Linux. CERT/CC ha sottolineato il mese scorso che diversi bootloader specifici dei fornitori non erano stati aggiornati per recepire le correzioni del progetto upstream, pur essendo le vulnerabilità già note e corrette.
Il risultato è una tipica esposizione di supply chain: componenti vecchi, vulnerabili ma ancora firmati, rimangono eseguibili anche su sistemi completamente aggiornati dal punto di vista del sistema operativo.
In altre parole, un PC può risultare “patchato” nei report IT e tuttavia avere ancora una catena di avvio sfruttabile.
Questo è il motivo per cui il caso interessa anche chi gestisce parchi macchine Windows: la fiducia del firmware nel certificato Microsoft per componenti di terze parti può rendere sfruttabili questi shim indipendentemente dal sistema operativo installato.
I prodotti coinvolti
Microsoft ha revocato questi bootloader nell’aggiornamento del Patch Tuesday di giugno 2026, dopo una responsible disclosure avvenuta a febbraio 2026. Secondo quanto riportato, i componenti interessati sono 11:
- Spyrus WTGCreator da UEFI shim loader 0.7 o precedente
- Red Hat Enterprise Linux 7.2 da UEFI shim loader 0.9
- CentOS 7.2 da UEFI shim loader 0.9
- baramundi Management Suite fino alla versione 2024R1 da UEFI shim loader 0.8
- WhiteCanyon/Blancco WipeDrive dalla 8.0.0 alla 8.1.3 da UEFI shim loader 0.7
- Abitti 1 versione 1.0 da UEFI shim loader 0.8
- ROSA Linux R10 e R9 da UEFI shim loader 0.9
- Oracle Linux 7.2 da UEFI shim loader 0.9
- PC-Doctor Service Center 15 e 16 da UEFI shim loader 0.9
- OpenSUSE UEFI Shim loader 0.9
- OpenSUSE Shim 2.1 da UEFI shim loader 0.9
È un elenco eterogeneo: include distribuzioni, strumenti di diagnostica, soluzioni di cancellazione dati e software di gestione. Questo conferma che la superficie d’attacco può includere utility poco considerate nei normali inventari IT.
Quali sono i rischi reali per un’azienda
Per sfruttare il problema, l’attaccante deve avere privilegi amministrativi oppure la possibilità di modificare il processo di avvio. Non è quindi una falla “da internet” che si attiva da sola. Ma una volta ottenuto quel livello di accesso, l’impatto può essere molto serio.
Il motivo è semplice: se il malware si insedia prima del sistema operativo, può:
- eludere strumenti di sicurezza installati sul sistema;
- mantenere persistenza anche dopo riavvii;
- in alcuni casi sopravvivere perfino alla reinstallazione del sistema operativo;
- rendere più difficile l’analisi forense e la bonifica.
Per una PMI questo significa che un’infezione riuscita potrebbe trasformarsi da “problema su un PC” a incidente complesso, con tempi lunghi di fermo, dubbi sull’integrità dei sistemi e necessità di ricostruire la fiducia nella piattaforma.
Cosa significa per la tua azienda
La priorità non è creare allarmismo, ma verificare se nella tua infrastruttura esistono componenti di boot vecchi o strumenti che li includono.
Ecco le azioni più utili, in pratica:
-
Controlla gli aggiornamenti di giugno 2026 sui dispositivi interessati. La revoca dei bootloader vulnerabili è stata distribuita da Microsoft nel Patch Tuesday di giugno.
-
Fai un inventario degli strumenti di avvio e manutenzione. Non limitarti ai sistemi operativi installati: verifica chiavette di servizio, tool di diagnostica, software di wipe, immagini di deployment e utility usate dal reparto IT o dai fornitori.
-
Rivedi i supporti di boot interni. Se in azienda usate immagini storiche per installazioni, recovery o test hardware, potrebbero contenere shim obsoleti. È un dettaglio spesso trascurato.
-
Proteggi l’accesso amministrativo. Questa falla diventa davvero pericolosa quando un attaccante ha già ottenuto privilegi elevati. Ridurre gli account admin locali, applicare il principio del minimo privilegio e monitorare le modifiche al boot resta fondamentale.
-
Verifica la strategia di rilevamento e ripristino. Un bootkit UEFI è difficile da intercettare con i normali controlli endpoint. Servono procedure di ripristino affidabili e backup ben separati. Se vuoi rafforzare questo aspetto, una soluzione di remote backup riduce il rischio operativo in caso di compromissione persistente.
-
Includi firmware e catena di avvio nella postura di sicurezza. Spesso l’attenzione si concentra su patch del sistema operativo e antivirus. Oggi non basta più. Un assessment di sicurezza informatica dovrebbe considerare anche firmware, Secure Boot, supporti esterni e strumenti di manutenzione.
-
Documenta chi può modificare il boot process. Tecnici interni, outsourcer, software di gestione remota e utility di assistenza devono essere tracciati. Un buon processo di desktop IT management aiuta proprio a mantenere controllo, uniformità e aggiornamento dei client.
In sintesi: non è una vulnerabilità da affrontare solo con una patch. È un promemoria sul fatto che la sicurezza del PC inizia prima di Windows o Linux, nella catena di avvio e nei componenti fidati che spesso nessuno guarda.
Un segnale importante per la governance IT
Questo episodio mostra due lezioni utili per qualsiasi organizzazione.
La prima è che la firma digitale non equivale automaticamente a sicurezza. Un componente può essere firmato correttamente, ma restare pericoloso se è vecchio e non revocato.
La seconda è che la gestione degli asset invisibili — bootloader, firmware, supporti di manutenzione, utility dei fornitori — è ormai parte della sicurezza aziendale. Per molte PMI il punto debole non è il malware “sofisticato”, ma l’assenza di inventario e processi coerenti.
Quando si parla di continuità operativa, conformità e protezione dei dati, la domanda giusta non è soltanto “abbiamo aggiornato i PC?”, ma anche “sappiamo davvero con che cosa si avviano?”.
Domande frequenti
Questa vulnerabilità colpisce solo chi usa Linux?
No. Secondo la ricerca, il rischio riguarda i sistemi UEFI che si fidano del certificato Microsoft usato per componenti di terze parti, indipendentemente dal sistema operativo installato.
Basta aggiornare Windows o Linux per essere protetti?
Non sempre. Conta anche la revoca dei vecchi bootloader e la presenza di supporti o utility obsolete nella catena di avvio.
Un antivirus può bloccare questo tipo di attacco?
Non in modo affidabile nella fase iniziale, perché l’esecuzione avviene prima del caricamento del sistema operativo e dei normali strumenti di sicurezza.