Faille UEFI CVE-2026-97631 (EDK II, PXE)

Le 22 octobre 2026, le projet TianoCore a publié un avis de sécurité critique pour EDK II, l'implémentation open source de l'UEFI qui sert de base au firmware d'une grande partie des PC, des serveurs et des machines virtuelles. La faille, CVE-2026-97631, est notée 9,5 sur 10 (CVSS 4.0). Elle permet à un attaquant, sans aucun identifiant, d'exécuter du code sur une machine pendant qu'elle démarre par le réseau (PXE), avant que Secure Boot ou le système d'exploitation n'aient pu intervenir.

Sa particularité : il n'y a rien à installer aujourd'hui. Le code est corrigé dans le dépôt d'EDK II, mais l'avis ne cite aucune version corrigée, et le correctif doit encore passer par chaque éditeur de firmware puis par chaque constructeur avant d'arriver sous forme de mise à jour du BIOS. Cet article explique ce qui est en jeu, qui est concerné et ce que vous pouvez faire dès maintenant, sans attendre ces mises à jour.

UEFI, EDK II, PXE : de quoi parle-t-on

L'UEFI est le micrologiciel qui démarre la machine avant le système d'exploitation : il initialise le matériel, choisit sur quoi démarrer et, si Secure Boot est activé, vérifie que le chargeur de démarrage est signé. C'est le successeur du BIOS, et beaucoup l'appellent encore ainsi.

EDK II est le code de référence de l'UEFI, maintenu par la communauté TianoCore. Les éditeurs de firmware comme AMI, Insyde ou Phoenix s'en servent comme base, et OVMF, le firmware UEFI des machines virtuelles KVM/QEMU (Proxmox, OpenStack, libvirt), en fait directement partie. Une faille dans EDK II peut donc se retrouver chez un très grand nombre de constructeurs à la fois.

Le PXE est le démarrage par le réseau : au lieu de lire son disque, la machine demande une adresse IP, télécharge une image et démarre dessus. On s'en sert pour installer des parcs de serveurs, pour les postes sans disque, pour les modes de secours de serveurs dédiés ou pour réinstaller une machine à distance.

La faille, sans jargon

Pendant un démarrage PXE, le pilote réseau d'EDK II (NetworkPkg/UefiPxeBcDxe) écoute les messages d'erreur ICMP, ceux qu'un routeur envoie par exemple pour signaler qu'une destination est injoignable. Il recopie chaque message reçu dans une zone mémoire de taille fixe, 504 octets. Le calcul des limites de cette copie est faux, en IPv4 comme en IPv6 : un message plus long déborde de la zone et écrit des octets choisis par l'attaquant dans la mémoire voisine.

L'avis officiel décrit deux conséquences :

Le blocage du démarrage. Les données du pilote sont corrompues et le démarrage s'arrête sur une exception. Un attaquant peut ainsi empêcher une installation ou une restauration par le réseau.
L'exécution de code. Un attaquant qui connaît la version exacte du firmware visé peut glisser dans le même paquet un faux événement et faire exécuter ses propres octets par le firmware, au plus haut niveau de privilège, avant qu'aucun contrôle de sécurité du système n'existe.

Trois détails rendent la faille sérieuse. Il n'y a aucune authentification à franchir. Le message peut venir de loin : selon l'avis, il suffit d'un message ICMP adressé à l'IP de la machine, « depuis n'importe quelle distance réseau ». Enfin, le code s'exécute avant Secure Boot et avant le démarrage mesuré (TPM) : les deux protections conçues pour garantir l'intégrité du démarrage n'ont encore rien vérifié.

Il faut aussi dire ce qu'elle n'est pas. La fenêtre d'attaque ne dure que le temps du démarrage PXE : une machine qui démarre sur son disque n'utilise pas ce pilote. Et l'avis ne décrit pas d'écriture permanente dans la puce du firmware, seulement une exécution de code pendant ce démarrage-là. Ce qu'un attaquant en fait ensuite, servir une image piégée par exemple, dépend de son objectif.

Qui est concerné

Les machines qui démarrent par le réseau. Parcs installés par PXE (MAAS, Foreman, Cobbler, WDS, serveurs iPXE), postes réinstallés à distance, clusters de calcul.
Les machines où le réseau sert de repli. C'est le cas le plus sournois. Si le PXE figure dans l'ordre de démarrage après le disque, une panne de disque ou un ordre mal réglé suffit pour que la machine tente le réseau. Si le PXE passe avant le disque, la fenêtre s'ouvre à chaque redémarrage.
Les machines virtuelles en UEFI (OVMF) configurées pour démarrer sur leur carte réseau, ce qui est courant dans les modèles de VM et les outils de provisionnement.
Les serveurs dédiés dont le mode secours ou la réinstallation passent par un démarrage réseau. Ici, c'est l'hébergeur qui maîtrise le firmware et le réseau de démarrage : c'est à lui de dire s'il est exposé et ce qu'il fait.

Un VPS classique démarre sur son disque virtuel, et son firmware est géré par l'hébergeur : le risque direct y est faible, mais la question mérite d'être posée à votre fournisseur.

Côté versions, l'avis indique comme vulnérable « EDK II master au 14 septembre 2026 » et, comme version corrigée, « pas de correctif pour le moment ». Le correctif (requête de fusion n° 13302) a été intégré à la branche principale d'EDK II le 15 octobre. Il doit maintenant être repris par les éditeurs de firmware, puis par les constructeurs. Pour les machines virtuelles, NixOS a déjà intégré le correctif à son paquet OVMF, et Red Hat indique y travailler.

Vérifier si vos machines démarrent par le réseau

La question utile n'est pas « mon firmware est-il vulnérable ? », dont la réponse sera presque toujours « oui » ou « on ne sait pas », mais « ma machine tente-t-elle un démarrage PXE, et quand ? ».

Sur un serveur Linux démarré en UEFI, efibootmgr liste les entrées de démarrage et leur ordre :

# Mode UEFI ou BIOS hérité ? (ce dossier n'existe qu'en UEFI)
ls /sys/firmware/efi

# Entrées de démarrage et ordre
sudo efibootmgr -v
# BootOrder: 0003,0001,0000
# Boot0001* UEFI PXEv4 (MAC:...)   <- démarrage réseau IPv4
# Boot0000* UEFI PXEv6 (MAC:...)   <- démarrage réseau IPv6
# Boot0003* debian                 <- disque

Les intitulés varient selon le constructeur (« PXE », « IPv4 », « IPv6 », « Network », « NIC ») mais se repèrent vite. Si une entrée réseau figure dans BootOrder, la machine peut démarrer par le réseau. Sous Windows, bcdedit /enum firmware donne la même liste. Sur une machine virtuelle Proxmox, l'onglet « Options », rubrique « Boot Order », indique si l'interface net0 est cochée.

Sur un parc de serveurs physiques, l'interface d'administration à distance (iDRAC, iLO, XClarity, IPMI) affiche l'ordre de démarrage et la version du firmware sans redémarrer la machine : c'est l'outil de l'inventaire.

Se protéger en attendant les mises à jour du firmware

Tant qu'il n'existe pas de firmware corrigé, se protéger consiste à fermer la fenêtre d'exposition.

Désactiver le PXE là où il ne sert pas. C'est la mesure la plus efficace. Dans le setup UEFI, désactivez la pile réseau de démarrage (souvent « Network Stack », « PXE Boot » ou « IPv4/IPv6 PXE Support »), ou retirez les entrées réseau de l'ordre de démarrage. Sous Linux, sudo efibootmgr -o 0003 réduit l'ordre à la seule entrée disque (remplacez par le numéro de la vôtre) et sudo efibootmgr -b 0001 -A désactive une entrée.
Mettre le disque en premier et supprimer le repli réseau. Une machine qui doit rester démarrable par le réseau pour la maintenance doit au moins tenter son disque d'abord. Le démarrage réseau devient alors une opération ponctuelle, déclenchée à la main.
Déclencher le PXE à la demande. Les cartes d'administration à distance permettent de demander un démarrage réseau pour le prochain démarrage seulement (ipmitool chassis bootdev pxe, par exemple). C'est préférable à une entrée réseau permanente.
Isoler le réseau de démarrage. Là où le PXE est indispensable, il doit se faire sur un réseau (VLAN) dédié à l'installation, injoignable depuis Internet et depuis les autres réseaux de l'entreprise. Filtrez à son entrée les messages d'erreur ICMP et ICMPv6 qui ne viennent pas de vos propres équipements : c'est précisément le type de paquet qui porte l'attaque.
Machines virtuelles. Retirez l'interface réseau de l'ordre de démarrage des modèles et des VM qui n'en ont pas besoin, et mettez à jour le paquet OVMF de l'hyperviseur dès que votre distribution publie la version corrigée.

Préparer la vraie correction : la mise à jour du firmware

Le correctif définitif arrivera par la voie la plus lente de l'informatique : la mise à jour du BIOS/UEFI, constructeur par constructeur, modèle par modèle. C'est le moment de s'y préparer.

Faire l'inventaire : modèle et version de firmware de chaque machine. Sous Linux, sudo dmidecode -s system-product-name et sudo dmidecode -s bios-version donnent l'essentiel.
Surveiller les bulletins de vos constructeurs pour CVE-2026-97631. Sous Linux, fwupdmgr get-updates signale les mises à jour publiées sur le service LVFS pour les machines compatibles.
Planifier les redémarrages. Une mise à jour de firmware impose un redémarrage, parfois une interruption plus longue. Sur un poste chiffré avec BitLocker, gardez la clé de récupération à portée de main : une mise à jour du firmware peut la demander au démarrage suivant.

Ce que cette faille dit de votre maintenance

On met à jour son système chaque mois, ses dépendances chaque semaine, mais le firmware rarement, parfois jamais. C'est pourtant la couche la mieux placée pour contourner toutes les autres : un code qui s'exécute avant le système échappe à l'antivirus qui démarre après lui.

Réduire la surface. Une fonction de démarrage inutilisée (PXE, démarrage sur USB, ancienne compatibilité BIOS) est une porte qu'on n'a pas besoin de surveiller si elle est fermée.
Inventorier aussi le firmware. Savoir quelle version tourne sur quelle machine vaut pour le BIOS comme pour Node.js ou PHP. La même discipline est décrite à propos de la faille Node.js Brotli.
Compter avec le délai. Entre la correction du code et son arrivée sur vos machines, il peut se passer des mois, pendant lesquels le correctif est public et lisible par tous. Les mesures de contournement ne sont pas une solution d'attente : pendant ce temps, ce sont la protection principale.
Regarder tout le démarrage. Le même mois, l'expiration d'un certificat Secure Boot de Microsoft et le bootkit BlackX rappellent que la chaîne de démarrage se maintient comme le reste.

Ce que j'en retiens

CVE-2026-97631 touche le pilote PXE d'EDK II, le code de base de très nombreux firmwares UEFI : un message ICMP trop long, sans authentification, permet d'exécuter du code avant Secure Boot.
Seules les machines qui démarrent par le réseau sont exposées, et seulement pendant ce démarrage.
Il n'existe pas encore de firmware corrigé : le code est corrigé dans EDK II, les mises à jour des constructeurs suivront.
En attendant : désactiver le PXE là où il ne sert pas, mettre le disque en premier, isoler et filtrer le réseau de démarrage là où il est indispensable.
Le firmware fait partie de l'inventaire et de la maintenance, au même titre que le système et les applications.

Vous gérez des serveurs ou un parc de machines et vous ne savez pas lesquels démarrent par le réseau, ni sur quelle version de firmware ? Je peux faire l'inventaire avec vous, fermer ce qui doit l'être sans interrompre le service et organiser les mises à jour à venir. Décrivez-moi votre installation, je vous réponds rapidement.

Sources : avis de sécurité TianoCore GHSA-99cj-7hg9-mp4m du 22 octobre 2026 (GitHub, tianocore/edk2), requête de fusion edk2 n° 13302, article d'IT-Connect du 28 octobre 2026. Découverte créditée à Alex Matrosov (Anthropic) et Dan Holmes-Mitra (Google). Article à jour au 29 octobre 2026 ; les bulletins de votre constructeur et de votre hébergeur priment.

← Tous les articles