CVE-2026-97631 : une faille critique dans le firmware UEFI EDK II menace de nombreux serveurs
Un dépassement de tampon dans le pilote PXE d'EDK II (CVSS 9,5) peut permettre d'exécuter du code avant Secure Boot. Qui est concerné, pas d'exploitation connue, que faire.
Quand un serveur s’allume, il exécute d’abord un petit programme appelé firmware (UEFI), avant même le système d’exploitation. Une faille à ce niveau est très gênante : elle passe sous le radar des antivirus. C’est le cas de la CVE-2026-97631, révélée le 22 octobre 2026.
Ce qui est touché
La faille est un dépassement de tampon dans le pilote PXE d’EDK II, le code de référence open source de TianoCore sur lequel s’appuient de nombreux firmwares. Le PXE sert à démarrer une machine par le réseau. Le pilote copie des messages ICMP dans une zone mémoire de 504 octets sans vérifier leur taille, selon InformatiqueNews.
TianoCore l’a publiée le 22 octobre 2026 avec un score CVSS 9,5 sur 10, d’après la fiche OpenCVE. Red Hat la note 8,8 et indique que RHEL 8, 9, 10 et OpenShift 4 sont concernés. Elle a été découverte par Alex Matrosov (Anthropic) et Dan Holmes-Mitra (Google).
Ce qu’un attaquant peut faire
Un paquet réseau malformé peut faire planter le serveur. Un attaquant qui connaît le firmware visé peut, dans certains cas, exécuter du code avec les privilèges les plus élevés, avant Secure Boot, la protection qui vérifie le démarrage.
Il faut toutefois réunir plusieurs conditions : le pilote PXE doit être présent et utilisé, l’attaquant doit avoir un accès réseau adapté, et l’attaque doit être calée sur le firmware précis.
Exploitée ou non ?
Aucune exploitation active n’est documentée à ce jour. La faille n’est pas au catalogue KEV de la CISA (failles exploitées) et son score EPSS est très faible, selon OpenCVE. C’est une faille à traiter sans panique, mais sans attendre.
Les correctifs
Le correctif est intégré au code d’EDK II depuis le 15 octobre 2026. Mais chaque constructeur doit l’ajouter à son propre firmware (AMI, Insyde, Phoenix, Project Mu de Microsoft sont cités), et ces mises à jour sont lentes à arriver. La divulgation a été avancée après une publication sur GitHub fin septembre, alors que la date coordonnée était prévue en janvier 2027.
Que faire en entreprise
- Faites l’inventaire des serveurs qui démarrent par PXE.
- Surveillez les avis de vos constructeurs et appliquez les mises à jour de firmware dès leur sortie (voir comment prioriser les mises à jour).
- Désactivez le PXE là où il ne sert pas.
- Isolez le réseau de démarrage pour qu’un intrus ne puisse pas y envoyer de paquets.
Par Thomas Baros, consultant formateur en cybersécurité, Azure et DevOps.
Une question, une info à partager ? Contactez-moi.