Sommaire (6 sections)
Le 22 octobre, TianoCore a publié un avis de sécurité sur EDK II, le code ouvert qui sert de base au firmware UEFI de la plupart des serveurs et des PC. La faille, CVE-2026-97631, est notée 9,5 sur 10. Elle se trouve dans le pilote de démarrage réseau, PXE. Un attaquant peut faire exécuter son code pendant le démarrage, avant le système d'exploitation et avant Secure Boot. Six jours plus tard, aucun constructeur majeur n'a encore livré de correctif pour tous ses modèles. Voici ce qui est en jeu, qui est vraiment exposé, et ce qu'il faut faire en attendant.
Une faille au tout premier instant #
Quand un serveur démarre par le réseau, son firmware écoute les messages qui lui arrivent, dont les messages d'erreur ICMP, ceux qui disent qu'un hôte est injoignable. Le pilote PXE d'EDK II les recopie dans une zone de 504 octets. D'après l'avis, il contrôle mal leur taille, en IPv4 comme en IPv6 : un message plus long déborde de cette zone et écrase la mémoire voisine.
TianoCore décrit deux conséquences. La plus simple : le démarrage se fige. La plus grave : un attaquant qui connaît la version exacte du firmware visé peut faire exécuter ses propres octets dans la phase où le firmware prépare la machine, avec tous les droits. Il n'a besoin ni de compte ni de mot de passe : il lui suffit d'envoyer un message d'erreur ICMP à l'adresse IP de la machine pendant qu'elle démarre, et l'avis précise que cela peut se faire de n'importe où sur le réseau.
C'est le moment de l'attaque qui la rend sérieuse. Secure Boot vérifie le chargeur du système. L'antivirus, le pare-feu de la machine et les journaux arrivent encore après. Ici, tout se passe avant eux. Un code qui s'installe à ce niveau peut survivre à une réinstallation complète du système.
Une publication en avance sur les correctifs #
La chronologie explique pourquoi les correctifs manquent. Une première demande de modification qui cite la faille apparaît publiquement sur le dépôt d'EDK II le 28 septembre. La correction est fusionnée dans le code le 15 octobre, puis l'avis paraît le 22. Selon Thomas-Krenn, la publication était prévue pour début 2027 et n'aurait pas dû avoir lieu aussi tôt.
Or un correctif dans EDK II ne protège personne directement. Il doit d'abord passer chez les éditeurs de firmware (AMI, Insyde, Phoenix), puis chez chaque constructeur de cartes mères et de serveurs, carte par carte, avant d'arriver sous forme de mise à jour du BIOS. Supermicro a commencé à publier des versions corrigées pour certaines séries X12 et X13. Microsoft a intégré la correction à Project Mu le 28 octobre. Chez la plupart des autres, il faut encore attendre.
Côté machines virtuelles, la situation est un peu meilleure. Fedora a des paquets corrigés en test depuis le 26 octobre, NixOS a intégré la correction, Red Hat dit y travailler. Au moment où nous écrivons, Debian et SUSE listent le paquet comme vulnérable, sans correctif.
Qui est vraiment exposé #
La faille ne touche qu'une machine qui démarre par le réseau, et seulement pendant ce démarrage. Un serveur qui tourne n'est pas attaquable par ce biais. Un serveur qui démarre directement sur son disque, sans passer par le réseau, non plus. Trois situations demandent pourtant de l'attention.
La première concerne les serveurs dédiés chez un hébergeur. Pour pouvoir lancer un système de secours à distance, beaucoup de serveurs dédiés tentent un démarrage réseau à chaque mise sous tension, avant le disque. Hetzner a ouvert un incident le 28 octobre : pour ses serveurs dédiés, le risque existe à chaque redémarrage, et pour ses machines du cloud, au démarrage du système de secours. Hetzner conseille d'éviter les redémarrages tant que le correctif n'est pas là, et de bloquer l'ICMP entrant dans son pare-feu réseau pendant ceux qui sont indispensables.
La deuxième concerne les machines virtuelles en UEFI. Sous Proxmox, QEMU ou KVM, le firmware UEFI d'une machine virtuelle s'appelle OVMF, et OVMF est construit sur EDK II. Une VM qui a sa carte réseau dans son ordre de démarrage peut donc passer par le pilote vulnérable : si la carte vient avant le disque, ou si le disque ne démarre pas et que le firmware se rabat sur le réseau. Les VM en SeaBIOS, l'autre firmware proposé par Proxmox, ne sont pas concernées par cette faille-là. L'hyperviseur lui-même n'est exposé que par son propre firmware, comme n'importe quel serveur physique.
La troisième concerne les parcs installés par le réseau : postes et serveurs déployés par PXE, salles informatiques, machines qui démarrent sur le réseau par habitude. Là, la fenêtre s'ouvre à chaque démarrage.
Ce qu'il faut faire en attendant le correctif #
Commencez par savoir quelles machines démarrent en UEFI. Sous Linux, la présence du dossier /sys/firmware/efi suffit à le dire. Vérifiez ensuite, dans le BIOS ou la console de gestion de chaque serveur, si le démarrage réseau est activé et où il se trouve dans l'ordre de démarrage. Là où il ne sert à rien, désactivez-le. Là où il sert, placez-le après le disque.
Sous Proxmox, deux lignes de la configuration d'une VM répondent à la question : qm config <id> | grep -E '^(bios|boot):'. Si la VM est en ovmf et que sa carte réseau, net0 par exemple, figure dans l'ordre de démarrage, retirez-la quand elle ne sert pas, par exemple avec qm set <id> --boot order=scsi0. Gardez le lecteur de CD-ROM si vous en avez besoin. Le pare-feu de Proxmox peut en plus filtrer l'ICMP vers les VM qui doivent garder un démarrage réseau.
Ensuite, réduisez les fenêtres. Repoussez les redémarrages qui ne pressent pas, et pour ceux qui ne peuvent pas attendre, bloquez l'ICMP entrant en amont le temps du démarrage, puis rétablissez la règle. Chez Hetzner, pensez à autoriser les services de Hetzner dans la règle, sinon le système de secours et la surveillance de l'hébergeur ne fonctionnent plus.
Enfin, préparez le correctif. Pour les serveurs physiques, suivez les bulletins de votre constructeur (Dell, HPE, Lenovo, Supermicro…) : la mise à jour viendra par le BIOS, et Secure Boot ne vous en dispensera pas. Pour les VM, le correctif viendra par le paquet du firmware OVMF de l'hyperviseur, pve-edk2-firmware sous Proxmox. Une fois ce paquet à jour, une VM ne charge le nouveau firmware qu'après un arrêt complet suivi d'un démarrage : un simple redémarrage depuis l'intérieur de la VM ne suffit pas.
Ce que cette faille dit de l'hébergement #
Cette faille ne se corrige pas avec une commande de mise à jour lancée un soir. Elle demande de savoir comment chaque machine démarre, de filtrer en amont, de choisir le moment des redémarrages, puis de suivre des correctifs qui arriveront constructeur par constructeur pendant des semaines. C'est un travail d'inventaire et de patience, pas un réflexe.
Pour les serveurs que nous hébergeons et maintenons, ce travail fait partie du traitement de l'alerte : ordre de démarrage des serveurs et des VM vérifié, démarrage réseau retiré là où il ne sert pas, redémarrages planifiés derrière un filtrage en amont, puis firmware mis à jour dès que les constructeurs et Proxmox livrent leurs correctifs.
Vos serveurs ou votre cluster Proxmox sont gérés ailleurs, ou vous ne savez pas lesquels démarrent par le réseau ? Nous pouvons faire le point avec vous : quelles machines sont exposées, ce qu'il faut régler dès maintenant, et comment passer le correctif quand il sera là.
Sources #
- TianoCore, avis GHSA-99cj-7hg9-mp4m, Pre-boot RCE in EDK II PXE driver (22 octobre 2026) : description, score CVSS 4.0 de 9,5, crédits.
- EDK II, demande de modification n° 13200 (28 septembre 2026) et correction fusionnée, n° 13302 (15 octobre 2026).
- Hetzner, incident CVE-2026-97631 (ouvert le 28 octobre 2026) : risque au redémarrage, recommandations sur le pare-feu.
- Thomas-Krenn, Kritische PXE Boot Sicherheitslücke in EDK2 (mis à jour le 30 octobre 2026) : publication anticipée, versions corrigées du BIOS Supermicro.
- Red Hat, fiche CVE-2026-97631.
- NixOS, intégration de la correction.
- IT-Connect, Faille UEFI EDK II : un paquet ICMP pour exécuter du code avant Secure Boot (28 octobre 2026).
