CVE-2026-97631 : faille UEFI EDK II CVSS 9.5 — RCE pré-démarrage OS

Les faits

Le 27 octobre 2026, les chercheurs de Binarly ont divulgué une vulnérabilité critique dans TianoCore EDK II, le code de référence open source utilisé par la quasi-totalité des fabricants de firmware UEFI pour serveurs et postes professionnels. Identifiée CVE-2026-97631 et notée 9,5 au CVSS v4, cette faille permet à un attaquant en position réseau d'exécuter du code arbitraire sur une machine cible avant le démarrage du système d'exploitation — c'est-à-dire avant que Secure Boot, les mesures TPM ou les EDR système ne soient chargés et actifs.

La vulnérabilité réside dans le driver UefiPxeBcDxe, responsable du démarrage par réseau via le protocole PXE (Preboot eXecution Environment). Durant la phase de boot PXE, ce driver écoute les messages d'erreur ICMP émis par le réseau et les copie dans un tampon de taille fixe de 504 octets. Le problème : la vérification de la taille du message ICMP entrant est insuffisante dans les handlers IPv4 et IPv6. Un attaquant peut envoyer un message ICMP forgé dépassant 504 octets, provoquant un out-of-bounds write et une corruption mémoire contrôlée menant à l'exécution de code arbitraire. Le NVD/NIST a publié l'avis le 27 octobre 2026, confirmant le vecteur réseau (AV:N) et la complexité d'attaque faible (AC:L).

La criticité de CVE-2026-97631 tient à son positionnement dans la chaîne de démarrage. EDK II constitue la base de nombreux firmwares UEFI commerciaux : AMI Aptio, Insyde H2O, Phoenix SecureCore et les implémentations OEM de Dell, HPE, Lenovo et Supermicro s'appuient toutes sur des portions du code EDK II. Exploitée avec succès, la faille permet d'implanter du code au niveau firmware — un implant qui survivrait à une réinstallation complète du système d'exploitation et résisterait à la plupart des outils de détection standards. La Red Hat a publié son avis de sécurité le 27 octobre 2026, classant l'impact comme critique pour les datacenters utilisant OVMF (Open Virtual Machine Firmware, basé sur EDK II) pour la virtualisation KVM/QEMU.

Pour exploiter CVE-2026-97631, l'attaquant doit être en mesure d'envoyer des paquets ICMP forgés sur le même segment réseau qu'une machine en cours de boot PXE. Ce vecteur est particulièrement pertinent dans les datacenters où le déploiement automatisé de serveurs repose sur le boot réseau (bare-metal provisioning, PXE/iPXE). Dans un scénario réaliste, un acteur ayant compromis un équipement réseau sur le VLAN de provisioning — switch, routeur, serveur DHCP ou TFTP — pourrait cibler tous les serveurs en phase de déploiement. Les hyperviseurs Proxmox VE, oVirt et RHEV utilisant OVMF pour les guests UEFI sont également concernés. VMware ESXi n'est pas directement affecté selon Broadcom.

La divulgation coordonnée a été initiée le 12 septembre 2026, avec un correctif intégré dans la branche principale d'EDK II (commit ee7a71b, tag edk2-stable202610) le 20 octobre 2026. Cependant, le délai entre l'intégration dans EDK II upstream et la disponibilité des mises à jour firmware OEM varie de plusieurs semaines à plusieurs mois. Au 27 octobre 2026, Dell, HPE et Lenovo avaient émis des advisories sans date définitive pour l'ensemble de leur catalogue serveur. La Debian Security Team a publié un DLA pour les packages ovmf et edk2 le même jour, avec backport disponible pour Debian 11 (Bullseye) et 12 (Bookworm). Fedora et openSUSE ont publié leurs mises à jour le 27 octobre. Les systèmes utilisant CoreBoot ou libreboot ne sont pas affectés.

Un point important : si PXE est activé dans l'ordre de boot UEFI, le driver UefiPxeBcDxe est initialisé et écoute sur le réseau même si la machine finit par démarrer sur son disque local. La fenêtre d'exposition existe donc même sans utilisation effective du boot PXE. L'activation de PXE dans le firmware est suffisante pour rendre la machine vulnérable pendant sa phase de démarrage.

À la date de publication, aucune exploitation active confirmée n'a été signalée par le CERT-FR ni la CISA. La CVE n'a pas encore été ajoutée au catalogue KEV (Known Exploited Vulnerabilities) de la CISA. Cependant, la disponibilité du code source EDK II sous licence BSD facilite l'analyse de la faille et potentiellement le développement d'un PoC par des chercheurs ou des acteurs malveillants. Les chercheurs de Binarly ont annoncé ne pas publier de code d'exploitation.

Cette vulnérabilité rappelle les incidents LogoFAIL (2023) et PixieFail (2024), qui avaient démontré que le firmware UEFI constitue une surface d'attaque significative longtemps négligée. Les implants firmware de niveau UEFI ont été utilisés par des APT étatiques (notamment les groupes liés à la Russie documentés par ESET sous les noms LoJax et MoonBounce) précisément parce qu'ils survivent aux réinstallations OS et échappent à la quasi-totalité des solutions de détection standards.

Impact et exposition

Les environnements les plus exposés sont les datacenters utilisant le boot PXE pour le déploiement automatisé, les infrastructures de cloud privé avec provisioning bare-metal, les hyperviseurs Linux (Proxmox, RHEV, oVirt) utilisant OVMF pour les guests UEFI, et les environnements de laboratoire IT. Les postes de travail professionnels avec PXE activé par défaut sont également concernés, bien que l'exploitation y soit plus difficile. Les utilisateurs domestiques ne sont pas affectés.

Recommandations

• Immédiat : désactiver le boot PXE dans les paramètres UEFI de tous les serveurs qui n'en ont pas besoin opérationnellement
• Isoler le VLAN de provisioning PXE par des ACL réseau strictes, limitant l'accès aux seuls serveurs DHCP/TFTP autorisés
• Appliquer les mises à jour firmware UEFI dès leur disponibilité auprès de votre fournisseur (Dell BIOS update, HPE SPP, Lenovo XClarity)
• Mettre à jour immédiatement les packages ovmf et edk2 sur les hyperviseurs Linux
• Surveiller les logs DHCP/TFTP pour détecter des requêtes PXE anormales