Un paquet ICMP pendant le démarrage PXE exécute du code avant le Secure Boot
Le 22 octobre 2026, TianoCore publie un bulletin sur CVE-2026-97631, un dépassement de tampon (CVSS 4.0 : 9,5) dans le pilote PXE d’EDK II qui laisse un paquet ICMP forgé exécuter du code en ring 0 avant toute vérification du Secure Boot. Vérifiez l’ordre de démarrage de vos serveurs et désactivez le PXE partout où il n’est pas indispensable, car aucun firmware corrigé n’est encore distribué.
22 octobre 2026. Le projet TianoCore publie un bulletin de sécurité (GHSA-99cj-7hg9-mp4m) sur EDK II, l’implémentation open source de la spécification UEFI utilisée par les grands fournisseurs de firmware — AMI, Insyde et Phoenix. CVSS 4.0 : 9,5. La faille, CVE-2026-97631, touche le pilote de démarrage réseau PXE. Un seul paquet ICMP. C’est ce qui suffit, selon les chercheurs Alex Matrosov (Anthropic) et Dan Holmes-Mitra (Google), pour exécuter du code avant même que Secure Boot n’ait vérifié quoi que ce soit.
Un dépassement de tampon dans le pilote PXE
Le défaut se situe dans NetworkPkg/UefiPxeBcDxe, le pilote PXE d’EDK II. Pendant un démarrage réseau, ce pilote copie chaque message d’erreur ICMP reçu dans un champ de taille fixe de 504 octets. Or la gestion des limites de cette copie est incorrecte, en IPv4 comme en IPv6 : un message trop long déborde du champ et écrit des données contrôlées par l’attaquant dans la mémoire adjacente. C’est un dépassement de tampon classique, logé au cœur de la phase DXE du firmware — celle qui initialise le matériel juste avant la main au système d’exploitation.
Le bulletin décrit deux issues. La première est un déni de service : la corruption des données du pilote provoque une exception du processeur dans le cœur DXE, et le démarrage se fige. La seconde est l’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.
Le point qui change tout : 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. Le Secure Boot vérifie ce qui vient après le firmware — le chargeur, le noyau, les pilotes signés. Ici, la compromission se produit dans le firmware lui-même, donc en amont de tout ce que Secure Boot peut contrôler.
Pourquoi le démarrage réseau est l’angle mort du firmware
Le démarrage PXE est le parent pauvre de la sécurité firmware. Les équipes durcissent Secure Boot, le TPM, le measured boot, les révocations de certificats — et laissent souvent le PXE activé « au cas où », pour un déploiement automatisé ou un plan de reprise. C’est précisément cette surface que la CVE-2026-97631 transforme en point d’entrée.
La fenêtre d’exploitation est courte — elle correspond à la durée du démarrage réseau — mais elle se répète à chaque redémarrage dès lors que le PXE est placé avant le disque dans l’ordre de boot, ou configuré comme solution de repli. Un serveur qui démarre sur son disque local ne passe pas par ce pilote ; un serveur qui tente le réseau à chaque cycle, lui, rejoue la vulnérabilité à chaque amorçage. L’attaquant n’a pas besoin d’être sur le même segment qu’à un instant précis : il lui faut être en mesure d’émettre un paquet ICMP vers la machine au moment où elle cherche une adresse réseau.
Le périmètre est massif. L’EDK II étant la base de la plupart des BIOS/UEFI du marché, la faille concerne potentiellement des millions de machines, serveurs compris. Et la virtualisation n’est pas épargnée : le firmware OVMF des machines virtuelles UEFI embarque le même code.
Un correctif sans version distribuée
L’histoire du correctif illustre le goulot d’étranglement de la chaîne firmware. La pull request 13302 qui porte la référence CVE a été fusionnée dans la branche principale d’EDK II le 15 octobre 2026. Le code amont est donc corrigé. Mais le bulletin du 22 octobre n’affiche toujours aucune version corrigée : le patch doit encore traverser chaque fournisseur de firmware, puis chaque constructeur, avant d’atteindre les machines sous forme de mise à jour BIOS/UEFI.
La virtualisation avance plus vite. NixOS a intégré le patch dans son paquet OVMF, et Red Hat indique travailler à un correctif. Pour les serveurs physiques, en revanche, le délai se compte en semaines, voire en mois, selon la réactivité de chaque constructeur et l’ancienneté de la plateforme — les machines en fin de support risquant de ne jamais recevoir de correctif du tout.
# Sur un hôte Linux, repérer l'ordre de démarrage et la présence du PXE
efibootmgr -v
# Désactiver une entrée PXE si elle n'est pas nécessaire (numéro d'entrée indicatif)
efibootmgr -b 0004 -ALe réflexe à corriger est de croire que « le firmware est à jour » : ici, aucun firmware n’est à jour, car aucun n’est distribué. La protection immédiate ne vient pas du patch, mais de la réduction de surface — désactiver le démarrage réseau là où il ne sert pas, et durcir l’ordre de boot.
Le déroulé d’une attaque, pas à pas
Le scénario se déroule en quatre temps, tous antérieurs au chargement du système. D’abord, la machine amorce en PXE et diffuse une requête d’adresse sur le réseau ; le pilote UefiPxeBcDxe écoute les réponses DHCP et les messages ICMP associés. Ensuite, l’attaquant — présent sur le même VLAN de boot, ou en mesure d’y injecter un paquet — répond avec un message d’erreur ICMP trop long. Le pilote le copie dans son champ de 504 octets sans vérifier les bornes, et le débordement écrase la mémoire adjacente. Troisième temps : si l’attaquant connaît la version exacte du firmware, il insère dans ce même paquet un faux événement qui fait exécuter ses octets en phase DXE, en ring 0. Quatrième temps : ce code s’exécute avant que Secure Boot ou le démarrage mesuré n’aient vérifié le moindre composant — la machine est compromise avant même d’avoir commencé à démarrer.
Le point sur le measured boot mérite d’être martelé : mesurer un composant suppose qu’il se charge après l’établissement de la racine de mesure. Ici, la compromission se produit dans le firmware, donc avant cette racine. Le journal du TPM ne contiendra aucune trace de l’exécution malveillante, car rien n’était encore en état de la mesurer. C’est ce qui distingue cette faille d’un simple contournement de Secure Boot : elle se situe en amont de toute la chaîne de confiance, là où aucune vérification n’a encore été conçue.
La mitigation immédiate est donc réseau avant d’être logicielle. Isolez le trafic de démarrage sur un VLAN dédié, activez le DHCP snooping et la protection des sources sur les commutateurs qui voient le boot, et n’exposez le PXE qu’aux machines qui en ont réellement besoin. Un serveur qui n’amorce jamais par le réseau n’a aucune raison d’écouter ces paquets — et chaque paquet non écouté est une surface d’attaque refermée.
Verdict
Si vos serveurs démarrent en PXE — déploiement automatisé, reprise après sinistre, bare-metal as a service — considérez-les exposés tant que les firmwares corrigés ne sont pas livrés, et privilégiez le HTTP Boot UEFI ou le démarrage local quand c’est possible. Si le PXE n’est pas indispensable, désactivez-le et placez le disque avant le réseau dans l’ordre de démarrage : c’est la seule mitigation réellement disponible aujourd’hui. Pour les machines virtuelles, appliquez sans attendre les mises à jour OVMF de votre distribution. Et si vous gérez un parc de serveurs physiques, dressez l’inventaire des plateformes qui amorcent par le réseau et suivez, constructeur par constructeur, l’arrivée du correctif — le patch amont existe, mais la chaîne qui doit le porter jusqu’à vos machines n’a pas encore rendu sa copie.