Le 22 octobre 2026, le projet TianoCore a publié un bulletin sur CVE-2026-97631, une faille critique du pilote de démarrage réseau PXE de l’UEFI EDK II. Un paquet ICMP piégé suffit à provoquer un dépassement de tampon et, dans certains cas, à exécuter du code avant que Secure Boot ne vérifie quoi que ce soit. Le sujet est moins médiatique que la faille PHP de la même semaine, mais il concerne directement les postes et serveurs qui démarrent par le réseau.
Ce qui est établi
- Composant : le pilote
NetworkPkg/UefiPxeBcDxed’EDK II, base de code UEFI utilisée par plusieurs fournisseurs de firmware (AMI, Insyde, Phoenix). - Cause : le pilote copie chaque message d’erreur ICMP dans un champ de 504 octets, et la vérification des limites est incorrecte, en IPv4 comme en IPv6.
- Gravité : score CVSS 4.0 de 9,5 sur 10 selon IT-Connect. Aucune authentification n’est requise.
- Impacts : déni de service (le démarrage se bloque), ou exécution de code en phase DXE avec les privilèges les plus élevés, pour un attaquant qui connaît la version exacte du firmware.
- Correctif : intégré à la branche principale d’EDK II le 15 octobre 2026. Le bulletin n’indique pas encore de version corrigée : les fournisseurs de firmware, puis les constructeurs, doivent publier des mises à jour BIOS/UEFI.
- Machines virtuelles : pour le firmware OVMF, NixOS a intégré le correctif et Red Hat indique y travailler.
La fenêtre d’attaque est étroite
L’attaque ne se joue que pendant le démarrage PXE. Une machine qui démarre sur son disque local n’utilise pas ce pilote. Le risque réel concerne donc :
- les parcs déployés par PXE (Windows Deployment Services, MDT, serveurs de déploiement, clusters qui démarrent par le réseau) ;
- les postes dont l’ordre de démarrage place le réseau avant le disque, ou en repli ;
- un attaquant qui doit, en pratique, pouvoir envoyer du trafic à la machine pendant son démarrage.
Que faire
-
Revoir l’ordre de démarrage. Si le PXE est placé avant le disque, ou en repli, la machine s’expose à chaque redémarrage. Le désactiver dans le BIOS/UEFI quand on ne s’en sert pas (voir l’aide-mémoire BIOS/UEFI pour les touches d’accès selon les constructeurs).
-
Protéger l’accès au BIOS/UEFI par un mot de passe, pour que le réglage ne soit pas défait.
-
Isoler le réseau de déploiement. Les installations PXE se font sur un VLAN dédié, pas sur le réseau des utilisateurs.
-
Suivre les bulletins des constructeurs et appliquer les mises à jour de firmware dès qu’elles sortent. Pour connaître la version actuelle sous Windows :
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate -
Pour les machines virtuelles, surveiller la mise à jour du paquet OVMF de l’hyperviseur ou de la distribution.
À retenir
- Le firmware est une couche qu’on oublie dans l’inventaire des correctifs, alors qu’il s’exécute avant tout le reste.
- Le correctif existe dans le code source depuis le 15 octobre, mais il faudra attendre les mises à jour des constructeurs : d’ici là, la réduction de l’exposition (PXE désactivé, réseau isolé) est la seule protection.
- La faille a une portée limitée à la phase PXE, ce qui rend la mesure de contournement simple pour la plupart des petits parcs.
