Secu
Faille UEFI : les DSI et RSSI à nouveau en mode « panique »
Par Laurent Delattre, publié le 28 octobre 2026
Une semaine après PHP2Shell, une deuxième divulgation coordonnée déraille : une faille critique d’EDK II, le code de référence dont dérivent la plupart des firmwares UEFI des serveurs, s’est retrouvée exposée sur GitHub plus de trois mois avant la date prévue ! Une alerte qui tombe au pire endroit du SI : sous le système d’exploitation, au cœur du firmware, là où un correctif met souvent des mois à atteindre les machines qui animent notre univers numérique.
Les RSSI n’ont même pas fini de recenser leurs serveurs PHP qu’une nouvelle crise majeure pointe à l’horizon. La semaine dernière, PHP2Shell forçait préfectures et administrations européennes à débrancher leurs sites en urgence, après la fuite prématurée de deux failles critiques du moteur PHP. Il sera difficile d’en faire autant avec tous les serveurs de la planète si la nouvelle faille venait à être massivement exploitée par les cyberattaquants.
Nous revenions hier sur le mea culpa de la PHP Foundation en pointant notamment « une chaîne de divulgation trop étendue pour conserver un tel secret jusqu’au bout ». Nous ne pensions pas que l’actualité nous donnerait si vite raison et que la démonstration suivante viendrait dès le lendemain.
Le projet TianoCore a publié discrètement sur GitHub un bulletin de sécurité sur une vulnérabilité notée 9,5 sur 10 (CVSS v4) au cœur d’EDK II, le socle open source sur lequel repose la quasi-totalité des firmwares UEFI du marché. Un bulletin contraint et forcé. Les découvreurs de la faille visaient au départ une divulgation coordonnée en janvier 2027 pour laisser le temps à tous les constructeurs de préparer des mises à jour des firmwares. Mais AMI, l’un des fournisseurs de firmware dans la confidence, a publié le correctif sur GitHub dès la fin septembre… à la vue de tous ! TianoCore s’est retrouvé dans l’obligation de publier plus tôt que souhaitable son bulletin de sécurité. Contribuant ainsi un peu plus à briser la chaîne de divulgation et à mettre le monde numérique dans l’embarras.
Car il n’y avait pas forcément urgence puisqu’aucune exploitation de la faille n’a jusqu’ici été officiellement repérée. Désormais, les IA des cyberattaquants sont probablement déjà au travail pour mettre au point des exploits.
Une faille dans les fondations du démarrage
Référencée CVE-2026-97631, la faille se niche dans le pilote PXE (Preboot Execution Environment) d’EDK II, le composant qui permet à une machine de démarrer par le réseau plutôt que sur son disque interne. Pendant le démarrage réseau, le pilote écoute les messages d’erreur réseau (ICMP) et les copie dans une zone mémoire fixe de 504 octets. Or une anomalie du code fait que la copie ne vérifie pas si le message tient dans cette zone, ou s’il est trop long. Dès lors, un attaquant peut envoyer un message volontairement trop long, qui déborde de l’espace, entraînant soit un plantage au démarrage du serveur (avec souvent l’impossibilité de le restaurer) soit, pire encore, l’exécution d’un code malveillant avec les privilèges maximums et avant toute forme de protection ! Car la menace opère avant même le lancement de Secure Boot ! Et même si la charge injectée ne survit pas en elle-même au redémarrage, elle peut dès son exécution installer d’autres codes malveillants qui, dès lors, s’exécuteront très tôt à chaque démarrage. Sous l’EDR, sous l’hyperviseur, là où aucun bouclier classique ne regarde, voire ne peut regarder…
Ni authentification ni interaction ne sont nécessaires : il suffit de faire parvenir un message d’erreur ICMP à l’adresse IP de la machine pendant qu’elle démarre en PXE, d’où que l’on se trouve sur le réseau.
Bien sûr, il faut déjà s’être introduit dans le réseau et la fenêtre d’exposition se réduit à la phase de démarrage PXE, ce qui limite quand même les risques et nécessite des attaques plus élaborées que simplement repérer un serveur PHP exposé sur Internet comme dans le cas de PHP2Shell.
Mais, comme l’a dévoilé le document S-1 déposé par Anthropic auprès de la SEC, certains modèles d’IA sont aujourd’hui capables d’élaborer en quelques minutes des attaques très complexes à même d’exploiter jusqu’aux failles matérielles nichées au cœur des processeurs.
Par ailleurs, PXE est la colonne vertébrale du provisionnement dans les datacenters : installation des serveurs nus (« bare metal »), redéploiement d’images système, nœuds de calcul sans disque. Dans les datacenters des entreprises comme dans ceux des fournisseurs de cloud, la technologie PXE est très utilisée. Dans les paramétrages de bien des serveurs, le réseau s’affiche en tête de leur ordre de démarrage, ce qui rouvre la fenêtre d’exposition à chaque redémarrage. Ironie de l’affaire, le réflexe de réinstaller par le réseau un serveur compromis après un incident devient lui-même une porte d’entrée. Il y a donc des protections à prendre en amont pour éviter l’effet domino.
Ce qui affole les experts, c’est que le problème s’étend à un nombre considérable de constructeurs et que nombre d’entre eux sont pris de court. Maintenu par le projet TianoCore, EDK II sert en effet de base à pratiquement tous les fournisseurs de firmware UEFI, à commencer par AMI, Insyde et Phoenix, qui équipent à leur tour l’essentiel des serveurs, PC et appliances du marché.
Même Project Mu, la fameuse déclinaison durcie d’EDK II maintenue par Microsoft, embarquait elle aussi le composant vulnérable et a depuis intégré d’urgence le correctif.
Les firmwares virtuels ne sont pas épargnés : Red Hat classe comme affectés ses paquets edk2, notamment ceux de RHEL 8, 9 et 10, et Debian ceux de Bookworm, Trixie, Forky et Sid, ces paquets qui fournissent le firmware UEFI des machines virtuelles KVM et QEMU.
Le module réseau d’EDK II n’en est d’ailleurs pas à son coup d’essai : début 2024, les failles PixieFAIL mises au jour par Quarkslab frappaient déjà sa pile IPv6.
Apparemment, les serveurs Arm ne seraient pas vulnérables. Arm assure que la faille ne concerne pas directement son portefeuille.
Un correctif publié à la vue de tous
Pourtant, le vrai sujet d’inquiétude n’est pas tant la faille elle-même que la divulgation précipitée et incontrôlée d’une vulnérabilité de niveau critique qui affecte tant de machines sur le marché !
Il y a clairement quelque chose qui ne fonctionne plus, comme l’a déjà démontré PHP2Shell.
Les découvreurs, Alex Matrosov (Anthropic), vieux routier de la sécurité des firmwares et fondateur de Binarly, et Dan Holmes-Mitra (Google), avaient prévu une divulgation coordonnée en janvier 2027, délai qu’ils jugeaient indispensable pour laisser fournisseurs de firmware et constructeurs préparer leurs mises à jour.
Le premier loupé survient le 28 septembre lorsqu’un ingénieur d’AMI, manifestement dans la confidence puisque le numéro de CVE figure dans le titre, ouvre sur le dépôt GitHub public d’EDK II une « pull request », autrement dit une proposition de modification du code, qui décrit la cause du bug et apporte le correctif. La case signalant un impact de sécurité n’est même pas cochée (et c’est probablement ce manque qui fait qu’aucun attaquant ne s’est encore intéressé au sujet).
Personne ne donne l’alerte. Au contraire, les relecteurs du projet TianoCore travaillent… en pleine lumière. Le 7 octobre, un « steward » du projet (une sorte de gardien du temple, ingénieur chez Intel) publie une version remaniée du correctif, accompagnée de tests qui prouvent clairement l’existence du débordement de mémoire. Une semaine plus tard, faute de réponse de l’auteur initial, il ouvre sa propre pull request mais, cette fois, pense à effectivement l’étiqueter « sécurité », car l’équipe veut « résoudre le problème rapidement ». La pull request est approuvée et intégrée dans la branche principale d’EDK II le 15 octobre, moins de 24 heures après son ouverture.
Quiconque suivait les discussions publiques du projet pouvait dès lors comprendre qu’une faille de sécurité existait et qu’elle était en train d’être corrigée avant même que le moindre bulletin officiel ne soit publié.
L’embargo a été rompu de multiples fois, à de nombreux niveaux. Pour un loupé, c’est un gros loupé.
Un commentaire publié le 16 octobre sous ce correctif illustre en réalité toute l’étendue du problème. Un contributeur explique avoir signalé plusieurs vulnérabilités, avec les correctifs correspondants, par le canal confidentiel recommandé par TianoCore. Pourtant, certains de ses signalements restent sans réponse depuis près d’un an. À l’inverse, les failles signalées publiquement sont examinées et corrigées beaucoup plus vite. Il demande alors s’il doit, lui aussi, publier ses correctifs pour obtenir une réponse. Ça sent les dérapages à tous les niveaux. Et s’il doit y avoir panique en la demeure, c’est bien à ce niveau organisationnel et structurel.
La divulgation coordonnée craque de toutes parts
En une semaine, deux divulgations coordonnées majeures ont donc déraillé, par des mécanismes très différents. Avec PHP2Shell, la fuite est venue de la périphérie : identifiants de CVE lâchés sur des forums, vidéo de démonstration publiée par erreur par un chercheur, images de conteneurs corrigées diffusées avant l’heure par un distributeur. Avec EDK II, elle est venue du cœur du dispositif : un fournisseur dans la confidence et des mainteneurs qui relisent un correctif sensible sur la place publique.
La divulgation coordonnée a été pensée pour un monde où les failles critiques restaient rares, où le cercle des initiés tenait autour d’une table et où transformer un correctif en attaque exigeait des semaines d’expertise. Des hypothèses qui ne tiennent désormais plus. Faute à l’IA.
Sous l’effet des outils d’IA, les découvertes de failles se multiplient plus vite que les humains ne peuvent les gérer. Et les PoC et tentatives d’exploits arrivent désormais en même temps que les divulgations, voire avant.
Et comme l’IA a multiplié les compétences des cyberattaquants, les attaques se font par tous les biais possibles, ce qui met en tension une chaîne d’acteurs trop vaste : le cercle des initiés s’étend désormais aux fournisseurs de firmware, aux constructeurs, aux hyperscalers, aux distributions Linux, aux éditeurs de sécurité.
L’alerte ne doit pas être prise à la légère. Certes, dans le cas de PHP, la fuite n’avait avancé que d’une journée un calendrier déjà bouclé, avec des correctifs prêts à l’emploi. Dans le cas d’EDK II, elle intervient plus de trois mois avant l’échéance, avant que la chaîne industrielle du firmware ait eu le temps de produire ses mises à jour.
DSI et RSSI à nouveau sous haute pression
Un nouveau marathon vient de se déclencher. Le correctif de la faille CVE-2026-97631 existe. Mais chaque fournisseur de firmware doit d’abord l’intégrer dans ses propres bases de code, puis chaque constructeur doit ensuite recompiler et valider un nouveau BIOS pour chacune de ses plateformes. Et les DSI et RSSI vont devoir mettre en œuvre un plan de mise à jour d’un parc parfois composé de centaines ou de milliers de serveurs hétérogènes. Contrairement à un correctif Windows, une mise à jour de firmware exige des fenêtres de maintenance, des tests précautionneux (un flashage raté peut transformer un serveur en brique) et un traitement serveur par serveur. Et tout le monde n’est pas logé à la même enseigne : les clients du cloud public sont couverts par leur fournisseur, mais ceux du bare metal, de la colocation et du cloud privé portent seuls cette charge, sans compter les équipements sortis du support ou les appliances qui ne recevront jamais de correctif.
Plus complexe, la faille n’est probablement pas une arme de destruction massive comme PHP2Shell. Elle n’en est pas moins terrifiante. Car le profil d’attaquant qu’elle intéresse est aussi le plus redoutable : celui qui a déjà pris pied dans le réseau et cherche à s’installer durablement sous le système d’exploitation, à l’abri des défenses et des réinstallations.
Quant à la leçon, elle dépasse EDK II et tient en une phrase : il faut désormais raisonner collectivement comme si chaque alerte critique pouvait tomber sans préavis, et connaître son exposition avant l’alerte. Une affaire de gouvernance bien plus que de correctifs. Facile à dire. Bien plus compliqué à concrétiser…
Photo : Andrey_Popov / Shutterstock
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
