Onze chargeurs de démarrage UEFI signés par Microsoft et disponibles depuis des années permettaient de contourner Secure Boot sur la quasi-totalité des machines UEFI. Windows, Linux... Peu importe. Il suffisait de copier un vieux binaire sur la partition EFI pour exploiter cette faille. Voici ce que l'on sait sur ce problème de sécurité.

Sommaire

• Onze shims oubliés, une signature jamais retirée
• Aucun exploit inédit, un simple copier-coller suffit
• Comment se protéger ?

Onze shims oubliés, une signature jamais retirée

Avec le Secure Boot activé sur un PC, le firmware UEFI vérifie chaque application de démarrage en regardant deux bases : db, qui liste ce qui est autorisé, et dbx, qui liste ce qui est interdit. La plupart des fabricants intègrent le certificat Microsoft Corporation UEFI CA 2011 dans db dès la sortie d'usine. C'est lui qui signe les composants de démarrage tiers. Le problème lié à ce fonctionnement, c'est que cela impliquait de faire valider par Microsoft chaque nouvelle version de GRUB 2 ou du noyau. Ce qui n'est pas tenable, d'où le shim.

Ce chargeur est signé une seule fois par Microsoft, embarque le certificat de l'éditeur, puis prend le relais : c'est lui qui vérifie le composant suivant, généralement GRUB 2, qui charge ensuite le noyau. Une distribution Linux peut ainsi publier ses mises à jour sans repasser par la case Microsoft. La confiance du firmware s'arrête au shim, tout le reste en découle.

Le problème identifié par Martin Smolár, chercheur chez ESET, est le suivant : ces vieux shims signés n'ont jamais été révoqués. Soit 11 binaires en version 0.9 ou antérieure qui sont concernés, exploitables sur n'importe quelle machine qui fait confiance au certificat de 2011, quel que soit le système d'exploitation installé. Il est question des solutions suivantes :

• Les distributions Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2 et ROSA Linux R9/R10 (shim 0.9)
• Deux binaires côté OpenSUSE, dont le shim 2.1 (shim 0.9)
• La solution PC-Doctor Service Center 15 et 16 (shim 0.9)
• Le logiciel baramundi Management Suite, jusqu'à la version 2024R1 incluse (shim 0.8)
• Le logiciel Abitti 1.0, signé pour le Matriculation Examination Board finlandais (shim 0.8)
• L'utilitaire WipeDrive de WhiteCanyon/Blancco 8.0.0 à 8.1.3, et l'outil Spyrus WTGCreator (shim 0.7 ou antérieur)

ESET a signalé sa découverte au CERT/CC le 16 février 2026. La révocation, d'abord calée sur le Patch Tuesday de mai, a été publiée le 9 juin 2026, le temps que les éditeurs distribuent des shims de remplacement. Deux failles sont d'ailleurs associées à ce problème de sécurité : CVE-2026-8863 et CVE-2026-10797.

Aucun exploit inédit, un simple copier-coller suffit

Le logiciel vulnérable n'a pas besoin d'être installé sur la cible : l'attaquant apporte sa propre copie du shim et du binaire, les dépose sur la partition système EFI. La chaîne de confiance les acceptera, ce qui est un problème. C'est un peu le principe du BYOVD (Bring Your Own Vulnerable Driver) mais appliqué dans un contexte différent avec le shim. Alors attention, même si un simple copier-coller suffit, il faut déjà disposer des privilèges nécessaires sur la machine pour accomplir cette opération (mais pour de la persistance, c'est intéressant du point de vue d'un attaquant).

Selon le rapport d'ESET, un seul shim peut valider plusieurs binaires et les horodatages de signature et de compilation de ces binaires s'étalent de 2013 à 2025. "Le nombre de fichiers binaires considérés comme fiables par un shim donné varie : de moins de dix dans le cas de logiciels dédiés et spécialisés à près d'une centaine dans le cas de distributions Linux bien connues.", précise le rapport.

ESET donne trois illustrations de la surface d'attaque ainsi exposée :

• Le shim d'Oracle Linux 7.2 fait confiance à un GRUB 2 présent dans l'ISO d'Oracle Linux 7.1, affecté par la CVE-2015-5281. Les commandes multiboot et multiboot2 y autorisent le chargement de code non vérifié. Ni corruption mémoire, ni chaîne ROP : il suffit de compiler une image noyau conforme à multiboot2.
• Le shim 0.8 d'Abitti ignore la liste de révocation MokListX, dont l'application n'est arrivée qu'en version 0.9. Il permet donc de recharger des binaires qu'une entreprise croyait révoqués.
• Le shim 0.9 de Red Hat Enterprise Linux 7.2 est antérieur à la version 15.3, celle qui a introduit SBAT. Il ne consulte jamais la politique SbatLevel et charge sans broncher un GRUB 2 pourtant révoqué.

S'y ajoute la CVE-2026-10797, corrigée en amont il y a près de dix ans mais restée sans identifiant jusqu'à ce signalement par les chercheurs d'ESET. Les shims affectés lisaient la taille de la signature à deux endroits différents du binaire PE, ce qui permettait de faire porter le contrôle de révocation sur des données factices.

Et non, l'expiration du certificat ne règle rien. Vous avez peut-être tilté en lisant le début de cet article, lorsque j'ai mentionné le certificat Microsoft Corporation UEFI CA 2011. En effet, il a expiré le 27 juin 2026, mais cette date n'a aucun effet sur la vérification : tant que le certificat reste dans db sans être révoqué dans dbx, les binaires qu'il a signés restent dignes de confiance. L'occasion de vous remettre le lien vers mon article à propos de l'expiration des certificats Secure Boot en 2026.

"Ce qui rend ces vieux shims dangereux, ce n'est pas une vulnérabilité inédite, c'est qu'aucune nouvelle vulnérabilité n'est nécessaire pour contourner UEFI Secure Boot.", précise l'article publié sur WeLiveSecurity. Comme le rappelle ESET, ce problème de sécurité peut intéresser des menaces, notamment des bootkits comme BlackLotus, Bootkitty et le ransomware HybridPetya, dont le code s'exécute avant le chargement du système.

Maintenant que vous avez lu tout ça, vous avez probablement envie de protéger votre machine. La mesure de protection principale, c'est la suivante : appliquer les dernières révocations UEFI de Microsoft (distribuées depuis juin 2026).

Sur Windows, la mise à jour de dbx arrive via Windows Update. Pour savoir si vous avez déjà les bonnes listes installées sur votre système, exécutez le code PowerShell suivant proposé par ESET (il effectue une recherche spécifique sur des hash dans la base dbx) :

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
$notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
"All hashes revoked in dbx!"
}

Côté Linux, la mise à jour passe par le Linux Vendor Firmware Service et se vérifie avec le script uefi-dbx-audit. Vous pourrez le trouver sur cette page. Sur son site, le CERT/CC recommande de mettre à jour db avant de déployer les révocations dbx.

Retrouvez le rapport d'ESET sur cette page.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.