C’est le genre de découverte qui fait pâlir les responsables d’infrastructure : une faille critique dort depuis seize ans dans le code de démarrage de la plupart des serveurs en circulation, qu’ils tournent dans un datacenter d’entreprise ou chez un grand fournisseur de cloud. Référencée CVE-2026-97631 et notée 9,5 sur 10, elle loge dans EDK II, l’implémentation open source de référence de l’UEFI, ce logiciel qui s’exécute avant même le système d’exploitation.
Plan de l'article
Un dépassement de tampon dans le démarrage réseau PXE #
Le détail technique est documenté dans l’avis de sécurité publié par TianoCore le 22 octobre. La vulnérabilité se niche dans le pilote PXE d’EDK II (NetworkPkg/UefiPxeBcDxe), celui qui permet à une machine de démarrer depuis le réseau — un mécanisme omniprésent dans les parcs de serveurs, où l’on provisionne rarement les systèmes clé par clé.
Pendant cette phase de démarrage réseau, le firmware traite les messages d’erreur ICMP qu’il reçoit. Problème : il copie chaque message dans une zone mémoire fixe de 504 octets sans contrôler correctement la taille des données. Un paquet malformé suffit à écrire au-delà de cette zone, en IPv4 comme en IPv6. C’est un dépassement de tampon d’école, présent dans le code depuis seize ans.
À lire Inmac Store : Guide Achat Informatique 2026
Une exécution de code avant Secure Boot
Les conséquences vont du simple plantage au scénario noir. Un attaquant présent sur le réseau au moment du démarrage peut bloquer la machine. S’il connaît suffisamment le firmware visé, il peut aller beaucoup plus loin : faire exécuter son propre code avec les privilèges les plus élevés du processeur, avant les vérifications d’intégrité du système d’exploitation et avant Secure Boot. À ce niveau, un implant persistant devient invisible pour l’essentiel des outils de sécurité, qui s’exécutent bien plus tard dans la chaîne de démarrage.
La découverte est créditée à Alex Matrosov et Dan Holmes-Mitra, qui ont également proposé le correctif. Aucune exploitation active n’était documentée à la date de publication de l’avis — mais la fenêtre est désormais ouverte.
Pourquoi « la plupart des serveurs » sont concernés #
EDK II n’est pas un firmware parmi d’autres : c’est la souche dont dérivent les firmwares UEFI commerciaux d’AMI, d’Insyde et de Phoenix, ainsi que le Project Mu de Microsoft. Autrement dit, le code vulnérable a été recopié, adapté et embarqué dans d’innombrables cartes mères de serveurs — et une partie du parc de PC professionnels. Comme le résume InformatiqueNews, qui parle d’une faille menaçant « la plupart des serveurs des entreprises et des clouds », l’ampleur tient moins à la sophistication de l’attaque qu’à l’omniprésence du composant touché.
Trois conditions restent toutefois nécessaires pour une exploitation : le composant vulnérable doit être présent, la machine doit passer par une phase de démarrage PXE, et l’attaquant doit disposer d’un accès réseau à ce moment précis. C’est ce qui distingue cette faille d’un ver à propagation massive — sans la rendre moins sérieuse pour les environnements où le boot réseau est la norme.
À lire Geekom A6 : Test et Prix 2026
Une divulgation qui a dérapé
L’affaire est aussi un cas d’école de divulgation ratée. La publication coordonnée était initialement prévue pour janvier 2027, le temps que les constructeurs intègrent le correctif. Mais une contribution d’AMI publiée sur GitHub dès le 28 septembre a éventé le problème avant l’heure, forçant TianoCore à accélérer. Le correctif existe dans le code source d’EDK II, via une pull request dédiée — il n’est en revanche pas encore intégré dans les firmwares des constructeurs.
Ce que les équipes IT peuvent faire dès maintenant #
C’est là que le bât blesse. Une mise à jour de firmware ne se déploie pas comme un patch logiciel : chaque constructeur doit d’abord livrer une image corrigée pour chaque modèle de carte mère, puis chaque exploitant doit planifier des redémarrages sur son parc. Sur des milliers de serveurs en production, l’opération se compte en mois.
En attendant, les équipes peuvent réduire la surface d’exposition : désactiver le démarrage PXE partout où il n’est pas utilisé, isoler strictement les réseaux de provisioning sur lesquels il reste nécessaire, et surveiller les fenêtres de redémarrage des machines sensibles. Le démarrage réseau n’étant pas systématique, une machine qui ne boote jamais en PXE n’offre aucune prise à l’attaque.
Après LogoFAIL en 2023 puis PixieFail en 2024 — déjà dans la pile réseau d’EDK II —, cette nouvelle alerte confirme que le firmware est devenu un terrain de chasse à part entière. Pour les directions informatiques, la leçon est claire : l’inventaire des versions UEFI du parc et le suivi des bulletins des constructeurs ne sont plus des tâches de second rang, mais un volet central de la gestion des vulnérabilités.
