Faille UEFI CVE-2026-97631 : un paquet ICMP suffit pour exécuter du code avant le Secure Boot
Un seul message ICMP, envoyé au bon moment, et du code s'exécute sur une machine avant même que le Secure Boot ne vérifie quoi que ce soit. C'est le scénario d'attaque associé à une nouvelle faille de sécurité (CVE-2026-97631), découverte dans un code UEFI par deux chercheurs d'Anthropic et de Google. Voici ce que l'on sait sur cette vulnérabilité.
Le 22 octobre 2026, le projet TianoCore a publié un bulletin de sécurité consacré à une faille critique dans EDK II, l'implémentation open source de la spécification UEFI. Ce nom ne vous dit peut-être rien, et pourtant, c'est la base de code utilisée par de nombreux fournisseurs de firmwares, dont AMI, Insyde et Phoenix. Cette faille estampillée CVE-2026-97631 est associée à un score CVSS 4.0 de 9,5 sur 10, soit une belle faille critique !
Un dépassement de tampon pendant le démarrage PXE
La vulnérabilité découverte par Alex Matrosov (Anthropic) et Dan Holmes-Mitra (Google) se situe dans le pilote PXE (NetworkPkg/UefiPxeBcDxe). Pendant un démarrage réseau, il copie chaque message d'erreur ICMP reçu dans un champ de taille fixe de 504 octets. Sauf que la gestion des limites de cette copie est incorrecte, en IPv4 comme en IPv6. Un message trop long peut donc déborder du champ et écrire des données contrôlées par l'attaquant dans l'espace mémoire adjacent.
Le bulletin de sécurité publié par TianoCore présente deux risques :
Déni de service : la corruption des données du pilote provoque une exception CPU dans le cœur DXE, et le démarrage se bloque.
Exécution de code : un attaquant qui connaît la version exacte du firmware ciblé peut glisser un faux événement dans le même paquet et faire exécuter ses propres octets en phase DXE, avec les privilèges ring 0.
Aucune authentification n'est nécessaire, et le code s'exécute "avant que Secure Boot ou le démarrage mesuré n'ait vérifié ou mesuré le moindre composant" de l'OS, précise TianoCore.
Comment se protéger ?
Même si cette faille a été divulguée il y a quelques jours, le correctif, quant à lui, était visible sur GitHub bien avant. En effet, le 28 septembre 2026, une pull request portant la référence CVE a été ouverte sur le dépôt EDK II. Reprise par Michael D. Kinney, l'un des mainteneurs de ce projet open source, elle a abouti à la pull request 13302, fusionnée dans la branche principale le 15 octobre.
La bonne nouvelle : le code d'EDK II est corrigé, mais la mauvaise, c'est que le bulletin n'affiche toujours aucune version corrigée. Il doit encore passer par chaque fournisseur de firmware, puis par chaque constructeur, avant d'arriver sur vos machines sous la forme d'une mise à jour du BIOS/UEFI. Côté virtualisation (firmware OVMF des VM UEFI), les distributions avancent plus vite : NixOS a intégré le patch et Red Hat indique travailler à un correctif.
Cette faille de sécurité pourrait impacter des millions de machines, dont des serveurs, à partir du moment où l'EDK II est utilisé par le BIOS/UEFI. Pour autant, la fenêtre d'exploitation de cette faille est très courte : elle correspond à la durée du démarrage PXE. Cela veut donc dire aussi qu'un serveur qui démarre sur son disque local ne passe pas par ce pilote. Attention toutefois à l'ordre de démarrage : si le PXE est placé avant le disque, ou sert de solution de repli, la fenêtre d'exploitation est présente à chaque redémarrage.
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.