themalwareguardian/cve-2026-25250Analyse et exploitation de la CVE-2026-25250, un contournement de Secure Boot dans Horizon DataSys Reboot Restore où shdloader.efi charge Shield.efi sans vérification.
Un bootloader tiers signé par Microsoft qui charge un binaire EFI secondaire sans vérification de signature ni d'intégrité, effondrant la chaîne de confiance Secure Boot de l'intérieur.
Ce dépôt documente des recherches sur CVE-2026-25250, une vulnérabilité de contournement de Secure Boot divulguée à Microsoft et à laquelle un CVE a été attribué en avril 2026. Elle s'est rapidement démarquée comme l'un des problèmes de sécurité firmware les plus significatifs de l'année, précisément parce que le composant vulnérable est signé par Microsoft et donc inconditionnellement approuvé sur la grande majorité des systèmes Windows compatibles UEFI.
La vulnérabilité a été découverte par Mickey Shkatov et Stanislav Lyakhov chez Eclypsium, l'une des équipes de recherche en sécurité firmware et chaîne d'approvisionnement les plus en vue de l'industrie. Mickey Shkatov est une figure de longue date de la recherche offensive UEFI, auteur de BootHole (CVE-2020-10713, un contournement critique de Secure Boot GRUB2 qui a affecté pratiquement toutes les distributions Linux et configurations double démarrage Windows), et présentateur de « One Bootloader to Load Them All » à la DEF CON 30 aux côtés de Jesse Michael, une conférence qui a systématiquement catalogué comment les bootloaders tiers signés par Microsoft représentent une faiblesse de classe dans l'écosystème Secure Boot.
CVE-2026-25250 s'inscrit précisément dans cette classe.
Ce qui la rend particulièrement instructive, c'est sa simplicité : aucune corruption mémoire, aucune faille cryptographique dans le firmware lui-même, juste un binaire de confiance prenant une décision dangereuse sur ce qu'il charge ensuite. Un seul maillon faible suffit à effondrer l'intégralité du modèle Secure Boot pour un système cible.
CVE-2026-25250 a été découverte lors de l'analyse de composants de démarrage UEFI tiers déployés dans des environnements de récupération d'entreprise. Le produit concerné est la solution Reboot Restore de Horizon DataSys.
La vulnérabilité a été attribuée par MITRE plutôt que par Microsoft, car la faille réside dans un firmware tiers (shdloader.efi), et non dans Windows ou dans tout code rédigé par Microsoft.
Références officielles :
Centre de réponse sécurité Microsoft - Patch Tuesday d'avril 2026
Bulletin mensuel de mise à jour de sécurité.
Entrée CVE officielle. CVSS 6.0 - AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N. CWE-325 : Étape cryptographique requise manquante.
Divulgation technique Eclypsium
Divulgation de recherche originale de l'équipe de découverte, y compris le post LinkedIn qui a porté cette vulnérabilité à l'attention du public.
La divulgation d'Eclypsium, publiée sur LinkedIn par l'équipe de découverte, fournit suffisamment de contexte pour identifier le logiciel concerné et le télécharger directement depuis le site du fournisseur.
L'installateur Horizon DataSys Reboot Restore est publiquement disponible, et son installation sur un système de test place à la fois shdloader.efi et Shield.efi dans la partition système EFI, où ils peuvent être examinés statiquement ou observés à l'exécution.
Configuration de laboratoire recommandée :
Windows 10/11 VM (QEMU ou VMware)
├── Secure Boot : Activé
├── Horizon DataSys Reboot Restore : Installé
├── ESP accessible via : mountvol X: /S
└── Cibles :
HorizonDataSys
X:\EFI\shdloader.efi ← signé, approuvé, charge l'étape suivante
X:\EFI\Shield.efi ← chargé sans aucune vérification
Une fois installé, shdloader.efi peut être confirmé comme signé Microsoft CA 2011 via sigcheck.exe (Sysinternals) ou pesign. L'absence de tout appel LoadImage / StartImage dans le chemin de chargement de Shield.efi est visible immédiatement en analyse statique.
Cette vulnérabilité affecte une chaîne de démarrage multi-étapes, et non un binaire unique.
La vulnérabilité ne réside pas dans le firmware. Elle réside dans la logique d'un bootloader de confiance, un binaire déjà approuvé par le firmware, qui choisit de charger un binaire secondaire via un chemin de code contournant tous les contrôles de sécurité.
Firmware
└── vérifie shdloader.efi ✅ Microsoft CA 2011, approuvé
└── ManualPEParse(Shield.efi) ❌ pas de LoadImage, pas de vérification de signature
└── EntryPoint() 💥 code contrôlé par l'attaquant, pré-OS
Le périmètre Secure Boot n'est aussi solide que le binaire le moins prudent qu'il approuve.
CVE-2026-25250 est un contournement de Secure Boot causé par une validation incorrecte d'un binaire EFI secondaire chargé pendant le processus de démarrage. Le bootloader concerné (shdloader.efi) est signé et approuvé par Secure Boot, mais charge Shield.efi via une routine manuelle d'analyse PE sans aucune vérification cryptographique.
Il s'agit d'une défaillance de conception et de modèle de confiance : un composant approuvé prenant une décision dangereuse qui annule toutes les protections en aval.
Secure Boot impose une chaîne de confiance dans laquelle chaque composant exécuté pendant la séquence de démarrage doit être vérifié avant que le contrôle ne soit transféré. Le modèle ne tient que si chaque binaire approuvé dans la chaîne honore ce contrat :
Firmware → vérifie le bootloader → le bootloader n'exécute que du code vérifié
CVE-2026-25250 brise le deuxième maillon :
Firmware → vérifie shdloader.efi (✅ approuvé)
↓
shdloader.efi → charge Shield.efi (❌ non vérifié)
↓
Du code non signé arbitraire s'exécute avant le démarrage
L'application de Secure Boot au niveau du firmware devient sans objet dès qu'un binaire approuvé introduit un chemin d'exécution non vérifié.
Classée comme :
Une opération sensible à la sécurité est effectuée sans l'étape de vérification cryptographique requise, permettant à un attaquant de contourner la protection que cette étape aurait appliquée.
| Étape | Effectuée | Notes |
|---|
| Localiser Shield.efi sur l'ESP | ✅ | Accès standard au système de fichiers |
| Lire le fichier en mémoire | ✅ | - |
| Analyser manuellement les en-têtes PE | ✅ | Implémentation personnalisée |
| Vérifier la signature | ❌ | Non effectuée |
| Vérifier contre db / dbx | ❌ | Non effectuée |
| Appeler LoadImage / StartImage | ❌ | Contourné entièrement |
| Transférer l'exécution au point d'entrée | ✅ | Appel direct |
L'absence de LoadImage / StartImage est la cause racine. Ces services de démarrage UEFI sont le point d'intégration de l'application de la politique Secure Boot ; les contourner signifie contourner tout le reste.
L'exploitation nécessite un accès administrateur local et un seul redémarrage.
Au prochain démarrage, shdloader.efi s'exécute (approuvé par le firmware), charge le binaire contrôlé par l'attaquant et transfère l'exécution, pré-OS, pré-EDR, avant que toute politique de démarrage mesuré ne soit appliquée, sans aucune objection de Secure Boot.
Permet :
Eclypsium - Divulgation CVE-2026-25250
Recherche originale de Mickey Shkatov et Stanislav Lyakhov. Le post LinkedIn d'Eclypsium annonçant la découverte renvoie au logiciel Horizon DataSys, permettant une analyse indépendante.
Microsoft MSRC - Patch Tuesday d'avril 2026
Bulletin de sécurité Microsoft.
Entrée CVE officielle. Attribué par MITRE car la vulnérabilité réside dans un firmware tiers, et non dans du code Microsoft.
Eclypsium - BootHole (CVE-2020-10713)
Mickey Shkatov et Jesse Michael - contournement critique de Secure Boot GRUB2 affectant pratiquement toutes les distributions Linux et les systèmes double démarrage Windows.
DEF CON 30 - « One Bootloader to Load Them All »
Mickey Shkatov et Jesse Michael - analyse systématique des bootloaders tiers signés par Microsoft comme surface d'attaque Secure Boot de classe. CVE-2026-25250 est une instance directe de ce modèle de menace.
CWE-325 : Étape cryptographique requise manquante
Classification de la cause racine pour la vérification manquante dans le chemin de chargement de
shdloader.efi.
Spécification UEFI - Services de démarrage : LoadImage / StartImage
Les services de démarrage UEFI qui appliquent la politique Secure Boot - entièrement contournés par le chargeur PE manuel de
shdloader.efi.
Vous travaillez sur quelque chose de similaire ? Vous faites des recherches sur UEFI, la sécurité du noyau, l'exploitation, ou un autre sujet de sécurité intéressant ? Si vous avez besoin d'aide pour développer un exploit, explorer une technique, ou simplement échanger des idées, n'hésitez pas à me contacter. Je suis toujours ouvert à discuter de recherche, à aider là où je peux, et à collaborer sur des projets intéressants. N'hésitez pas à me contacter sur LinkedIn.