Un message d'erreur trop long pourrait suffire à pirater un serveur qui démarre par le réseau

Un message réseau d'erreur, trop long, envoyé au mauvais moment. Il pourrait suffire à faire tourner du code sur un serveur avant même que son système ne démarre. La faille, enregistrée sous la référence CVE-2026-97631, se cache depuis seize ans dans EDK II, le code libre du projet TianoCore sur lequel reposent les micrologiciels UEFI (le logiciel qui démarre la machine) de nombreux fabricants, via les fournisseurs AMI, Insyde ou Phoenix.

TianoCore a publié son avis le 22 octobre et note la faille 9,5 sur 10. Elle a été découverte par Alex Matrosov, chercheur chez Anthropic, et Dan Holmes-Mitra, de Google, selon l'avis. Elle ne concerne qu'un cas précis, mais fréquent dans les centres de données : le démarrage par le réseau, dit PXE, qui sert à installer ou redéployer des serveurs à la chaîne.

Ce qu'un attaquant pourrait faire

Pendant un démarrage PXE, en IPv4 comme en IPv6, le pilote réseau du micrologiciel recopie les messages d'erreur ICMP reçus dans une zone mémoire fixe de 504 octets. Un calcul de limites erroné permet à un message trop long de déborder. Selon l'avis de TianoCore, il suffit d'envoyer ce message à l'adresse de la machine, « depuis n'importe quelle distance réseau », tant que dure le démarrage.

La conséquence certaine est un blocage du démarrage. La plus grave reste conditionnelle : un attaquant qui connaît la version exacte du micrologiciel pourrait faire exécuter son propre code avant le démarrage sécurisé (Secure Boot) et avant tout outil de sécurité du système. HD Moore, de la société Dragos, a souligné auprès d'Ars Technica, cité par Hardware Busters, que la puce de sécurité TPM est alors accessible, et que contourner le chiffrement du disque fait partie des usages réalistes.

Plusieurs spécialistes tempèrent. Selon Jesse Michael, d'Eclypsium, cité par le même site, l'exploitation suppose de deviner des adresses mémoire : il faut adapter l'attaque à chaque modèle et à chaque version. Le code ne survit pas seul à un redémarrage, et aucune exploitation n'a été signalée.

Un correctif publié trop tôt

La divulgation était prévue pour janvier. Selon Ars Technica, cité par SecurityWeek, la publication d'un correctif par AMI a précipité les choses. La correction est intégrée au code principal d'EDK II, mais il faut maintenant que chaque fabricant reconstruise ses micrologiciels et les distribue. L'avis de TianoCore indiquait encore qu'aucune version corrigée n'était publiée. Bonne nouvelle, contrairement à d'anciennes failles de démarrage comme BlackLotus, aucune révocation de clés Secure Boot n'est nécessaire.

Que faire en attendant ?

• Si vos machines ne démarrent pas par le réseau, désactivez le démarrage PXE et la pile réseau UEFI dans les réglages du micrologiciel.
• Si vous en avez besoin, isolez le trafic de démarrage sur un segment réseau dédié.
• Surveillez les pages de support de vos constructeurs de serveurs et de cartes mères pour une mise à jour qui cite CVE-2026-97631, puis planifiez son déploiement.

Reste une question : combien de temps les fabricants mettront-ils à suivre ? Selon Hardware Busters, des milliers de micrologiciels de fabricants doivent chacun être reconstruits, validés puis installés.