Une vulnérabilité critique, CVE-2026-97631, touche le pilote de démarrage réseau PXE d’EDK II, le code de référence sur lequel reposent de nombreux firmwares UEFI. Un attaquant présent sur le réseau peut, pendant un démarrage PXE, bloquer la machine voire exécuter du code avant toute protection du système. Le correctif existe dans le code source, mais les mises à jour des constructeurs se font attendre : il faut agir sur la configuration de démarrage.
Une faille au cœur du firmware
Le bulletin publié par le projet TianoCore le 22 octobre 2026 décrit un dépassement de tampon dans le pilote UefiPxeBcDxe, qui gère le démarrage réseau. Lors d’un démarrage PXE, chaque message d’erreur ICMP reçu est recopié dans une zone de taille fixe, avec un contrôle des limites défaillant. Le défaut concerne aussi bien IPv4 qu’IPv6. TianoCore lui attribue une note de 9,5 sur 10 selon la version 4 du barème CVSS.
La faille a été signalée par Alex Matrosov, d’Anthropic, et Dan Holmes-Mitra, de Google ; TianoCore précise que tous deux ont aussi fourni la correction recommandée. Comme l’a rapporté IT-Connect le 28 octobre, EDK II sert de base aux firmwares de grands fournisseurs comme AMI, Insyde ou Phoenix, ce qui étend potentiellement le problème à des millions de PC et de serveurs, ainsi qu’aux machines virtuelles qui utilisent le firmware OVMF.
Pourquoi le risque est sérieux, mais circonscrit
Le danger tient au moment de l’attaque. Le code malveillant s’exécuterait pendant la phase DXE du firmware, en ring 0, bien avant les contrôles de Secure Boot et du démarrage mesuré. Les protections installées dans le système d’exploitation, comme un antivirus, ne s’appliquent donc pas à ce stade.
Plusieurs conditions limitent toutefois l’exposition :
- aucune authentification n’est requise, mais l’attaquant doit pouvoir envoyer des messages ICMP à la machine au moment où elle démarre sur le réseau ; selon Security Affairs, cela suppose un initié malveillant ou un attaquant déjà installé dans le réseau local ;
- une machine qui démarre sur son disque local n’utilise pas ce pilote ; la fenêtre ne s’ouvre que si le démarrage réseau passe avant le disque dans l’ordre de démarrage, ou intervient en secours ;
- l’exécution de code suppose de connaître la version exacte du firmware visé ; sans cette information, l’attaquant peut tout de même bloquer le démarrage.
Les évaluations divergent d’ailleurs.Aucune des sources consultées ne fait état d’une exploitation réelle.
Où en sont les correctifs
D’après IT-Connect, la correction a été intégrée à la branche principale d’EDK II le 15 octobre. Mais le bulletin de TianoCore n’indiquait encore aucune version corrigée au moment de sa publication, et ne propose pas de contournement. Pour les machines physiques, il revient aux fournisseurs de firmware, puis aux constructeurs, de reprendre la correction et de la livrer sous forme de mise à jour du BIOS. Security Affairs indique qu’AMI a publié un correctif dès septembre, sous la forme d’une demande de fusion sur le dépôt d’EDK II, ce qui a rendu les détails publics avant la date de divulgation prévue en janvier.
Côté virtualisation, la situation avance plus vite. IT-Connect signale que la distribution NixOS a déjà intégré le correctif dans son paquet OVMF, et que Red Hat travaille au sien.
Que faire dès maintenant
Les recommandations reprises par IT-Connect et Security Affairs sont avant tout de bon sens et s’appliquent aussi bien aux DSI qu’aux petites structures qui gèrent quelques serveurs :
- désactiver le démarrage PXE dans le BIOS lorsqu’il ne sert pas, ou le placer après le disque dans l’ordre de démarrage ;
- surveiller les journaux à la recherche d’une activité suspecte, comme le conseille Security Affairs ;
- appliquer les mises à jour OVMF des distributions sur les hôtes de virtualisation ;
- suivre les bulletins des constructeurs et planifier les mises à jour de firmware dès leur publication.
Cette faille rappelle que le firmware reste un angle mort de nombreuses politiques de mise à jour. Un inventaire des versions de BIOS installées facilite grandement le déploiement le jour où les correctifs arrivent.
Questions fréquentes
Mon ordinateur portable est-il concerné ?
Seulement s’il démarre sur le réseau en PXE. Security Affairs estime que les particuliers et les petits bureaux ne sont pas concernés, pas plus que les machines qui démarrent uniquement sur leur disque.
Secure Boot me protège-t-il ?
Non. Selon TianoCore et IT-Connect, le code s’exécuterait avant que Secure Boot n’entre en jeu, ce qui le rend inefficace contre cette attaque.
Quand les mises à jour BIOS seront-elles disponibles ?
Aucune date n’a été communiquée. Elles dépendent de chaque fournisseur de firmware et de chaque constructeur, qu’il faut surveiller.
Sources
- Faille UEFI CVE-2026-97631 : un paquet ICMP suffit pour exécuter du code avant le Secure Boot — IT-Connect, 2026-10-28
- Pre-boot RCE in EDK II PXE driver (GHSA-99cj-7hg9-mp4m) — TianoCore / GitHub (bulletin de sécurité), 2026-10-22
- CVE-2026-97631: 16-Year-Old UEFI Flaw Threatens Servers — Security Affairs, 2026-10-28