Introduction
Une faille critique notée 9,5 sur 10 au CVSS v4 vient d'être révélée dans EDK II, la base de code de référence sur laquelle la quasi-totalité des fabricants de serveurs bâtissent leur firmware UEFI. La particularité de CVE-2026-97631 : l'exploitation se produit avant même que le système d'exploitation ne commence à charger, rendant inopérantes les protections habituelles que sont le Secure Boot et le TPM.
Un débordement de tampon dans le pilote PXE
Le démarrage réseau (PXE) est une fonctionnalité centrale des grandes infrastructures IT : elle permet de provisionner des serveurs en masse depuis un serveur central, sans intervention physique sur chaque machine. C'est précisément dans ce flux que réside la vulnérabilité.
Le pilote incriminé — UefiPxeBcDxe dans le paquet NetworkPkg d'EDK II — copie les messages d'erreur ICMP reçus lors du démarrage réseau dans un tampon de taille fixe de 504 octets. Le problème : les gestionnaires IPv4 et IPv6 calculent mal la limite de copie. Un message ICMP surdimensionné écrase les données adjacentes en mémoire. Un attaquant positionné sur le réseau local peut envoyer une trame spécialement forgée pour déclencher l'un de deux scénarios : un crash immédiat qui bloque le démarrage, ou — plus grave — l'exécution de code arbitraire au niveau le plus privilégié du système, avant le chargement du moindre composant logiciel. L'exploitation ne requiert ni authentification ni interaction utilisateur.
Avant Secure Boot, avant TPM
Ce détail change tout. Les technologies comme Secure Boot ou la mesure d'intégrité via TPM interviennent après le firmware : elles ne peuvent rien contre une menace qui s'installe dans la séquence de démarrage elle-même. Un attaquant exploitant CVE-2026-97631 peut théoriquement implanter un code persistant que les couches logicielles supérieures ne verront jamais. La fenêtre d'exposition correspond à l'intégralité de la durée du démarrage PXE — ce qui, dans un datacenter qui provisionne des machines à la chaîne, représente une surface d'attaque permanente.
Le vrai problème : le délai entre correctif et firmware
Le code source d'EDK II a été corrigé le 15 octobre 2026 via la pull request #13302 dans le dépôt TianoCore, avec des vérifications de limites renforcées et une correction de l'arithmétique des pointeurs dans les deux gestionnaires. Mais ce correctif amont ne se traduit pas automatiquement par une protection pour les organisations.
Chaque fabricant — Dell, HP, Lenovo, Supermicro, et les éditeurs de couches firmware comme AMI, Insyde ou Phoenix — doit intégrer le correctif dans sa propre chaîne de build firmware, le valider sur ses plateformes matérielles, puis le distribuer via ses canaux de mise à jour BIOS. Dell a déjà publié un avis de sécurité dédié et amorcé des mises à jour pour plusieurs gammes. D'autres constructeurs suivront. Mais entre le moment où la correction existe dans le code de référence et celui où elle est disponible dans le firmware d'un serveur en production, les délais se comptent en semaines, parfois en mois selon les modèles et les générations de matériel.
Ce que les équipes IT doivent faire maintenant
En attendant le firmware corrigé de leur constructeur, les organisations peuvent réduire l'exposition dès aujourd'hui :
- Désactiver le démarrage PXE dans le BIOS/UEFI de tous les serveurs qui n'en ont pas l'utilité opérationnelle.
- Isoler le trafic de boot réseau sur un VLAN dédié, inaccessible depuis le reste du réseau de l'entreprise.
- Surveiller les avis constructeurs et mettre en place un suivi actif des CVE firmware — souvent absent des politiques de patch management classiques, qui s'arrêtent au niveau du système d'exploitation.
- Prioriser les mises à jour BIOS dès leur disponibilité pour les modèles concernés, au même titre qu'un correctif OS critique.
CVE-2026-97631 illustre une lacune structurelle dans la gestion des risques IT : le firmware est trop souvent traité comme un composant stable, exclu du périmètre de patch management. Il reste pourtant du logiciel — et comme tout logiciel, il peut porter des failles critiques. La sécurité d'un serveur commence avant son système d'exploitation.