RCE dans le pilote PXE d’EDK II avant Secure Boot (CVE-2026-97631)

TL;DR

• Pendant qu’une machine démarre en PXE sur IPv4 ou IPv6, un attaquant réseau non authentifié peut envoyer un message ICMP d’erreur surdimensionné qui corrompt la mémoire de l’environnement de démarrage UEFI. La corruption exécute des octets choisis avant le chargement du système d’exploitation. TianoCore a publié l’avis GHSA-99cj-7hg9-mp4m le 22 octobre 2026.
• L’exposition concerne tout micrologiciel fondé sur EDK II qui démarre depuis le réseau, avec un écouteur PXE joignable par l’attaquant pendant la fenêtre de démarrage. L’impact se produit avant que Secure Boot ou le measured boot n’aient vérifié ou mesuré un composant d’OS, donc ces défenses ne s’appliquent pas.
• L’enregistrement CVE de TianoCore le classe critique, CVSS v4.0 9,5. L’ADP de la CISA a enregistré l’exploitation comme absente le 30 octobre 2026, et le CVE ne figure pas dans le flux KEV vérifié le 1er novembre. Les sources citées ne fournissent pas de preuve de concept publique ; cela n’exclut pas une exploitation non divulguée.
• L’avis ne liste aucune version corrigée. Isolez les réseaux PXE et de provisioning du trafic non fiable, désactivez le démarrage réseau inutile et demandez à votre fournisseur si son micrologiciel inclut le correctif.

Suis-je concerné ?

Vous êtes exposé quand toutes ces conditions tiennent :

• Le micrologiciel de la machine inclut le pilote PXE Base Code vulnérable d’EDK II ou un dérivé.
• Le démarrage réseau PXE est activé et la machine démarre ou tente de démarrer depuis le réseau sur IPv4 ou IPv6.
• Un attaquant peut délivrer un message ICMP d’erreur en unicast à l’adresse IP de la machine pendant cette fenêtre de démarrage, depuis n’importe quelle distance réseau.

Les machines qui démarrent uniquement depuis un disque local ne sont pas exposées. La vulnérabilité se situe dans le chemin de démarrage réseau lui-même.

Les paquets Debian ci-dessus restent vulnérables ; vérifiez chaque micrologiciel auprès de son fournisseur. Identifiez le micrologiciel, puis vérifiez s’il démarre depuis le réseau :

# Firmware vendor and version string, to ask the vendor about EDK II content
dmidecode -s bios-vendor
dmidecode -s bios-version

Le démarrage PXE se configure dans le micrologiciel : inventoriez-le par serveur ou via les outils de provisioning. Demandez au fabricant si le micrologiciel installé inclut le pilote vulnérable et son correctif.

Comment corriger ?

L’avis ne liste aucune version corrigée. En attendant que le fournisseur confirme un micrologiciel corrigé, réduisez l’exposition :

1. Isolez les VLAN PXE et de provisioning des réseaux non fiables pour limiter la réception de messages ICMP malveillants pendant le démarrage réseau.
2. Désactivez le démarrage PXE et réseau sur toute machine qui n’en a pas besoin, ce qui supprime entièrement l’écouteur vulnérable.
3. Demandez le plan de micrologiciel à votre vendeur de serveurs, et appliquez la mise à jour dès sa sortie. Le correctif demande un changement de code simple et une mise à jour de micrologiciel, sans révocation de clé ni gestion de certificats, selon l’évaluation d’Eclypsium citée par Ars Technica.

Les limites sont claires. L’isolation réduit qui peut atteindre une machine en démarrage ; elle ne corrige pas le pilote. La désactivation du démarrage réseau supprime l’exposition uniquement sur les machines qui n’en ont jamais besoin. Rien en dessous de la couche réseau n’arrête le débordement tant qu’une image de micrologiciel corrigée n’est pas en cours d’exécution.

Quelle est la cause première ?

Le pilote PXE copie chaque message ICMP d’erreur reçu dans un champ de taille fixe sans borne fonctionnelle. La boucle fait ensuite avancer le pointeur de destination au-delà de ce champ.

Pendant le démarrage réseau, le pilote PXE Base Code dans NetworkPkg/UefiPxeBcDxe maintient une requête de réception ouverte pour les messages ICMP d’erreur. Il copie chaque message dans le champ fixe EFI_PXE_BASE_CODE_ICMP_ERROR, Mode.IcmpError, de sa structure d’état : une union d’en-tête ICMP de 8 octets suivie d’un tableau de données de 494 octets.

Le champ est défini dans MdePkg/Include/Protocol/PxeBaseCode.h :

typedef struct {
  UINT8     Type;
  UINT8     Code;
  UINT16    Checksum;
  union {
    UINT32    reserved;
    UINT32    Mtu;
    UINT32    Pointer;
    struct {
      UINT16    Identifier;
      UINT16    Sequence;
    } Echo;
  } u;
  UINT8    Data[494];
} EFI_PXE_BASE_CODE_ICMP_ERROR;

La boucle de copie dans PxeBcSupport.c traitait les fragments du message reçu, dans les gestionnaires IPv4 comme IPv6, ainsi avant le correctif :

  CopiedLen = 0;
  IcmpError = (UINT8 *)&Mode->IcmpError;

  for (Index = 0; Index < RxData->FragmentCount; Index++) {
    CopiedLen += RxData->FragmentTable[Index].FragmentLength;
    if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        RxData->FragmentTable[Index].FragmentLength
        );
    } else {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        CopiedLen - sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)
        );
    }

    IcmpError += CopiedLen;
  }

Deux défauts invalident la borne. Lorsque la longueur cumulée dépasse le champ, la branche else copie la longueur excédentaire au lieu de la capacité restante. Selon les fragments, cette écriture peut dépasser le champ de destination.

La boucle fait aussi avancer IcmpError de CopiedLen, le total courant, au lieu de la longueur du fragment en cours, donc le curseur d’écriture dérive un peu plus hors limites à chaque fragment. Rien en amont du chemin de réception ne limite la longueur du message. Un seul message ICMP d’erreur surdimensionné écrit donc des octets contrôlés par l’attaquant au-delà de Mode.IcmpError, dans les données adjacentes du pilote.

Comment la faille est-elle exploitée ?

L’attaque tient en un paquet unicast pendant une fenêtre de démarrage, selon l’avis :

1. La machine entre dans un démarrage PXE sur IPv4 ou IPv6, et la requête de réception des messages ICMP d’erreur du pilote devient active.
2. L’attaquant envoie un message ICMP d’erreur en unicast adressé à l’adresse IP de la machine, plus grand que le champ IcmpError et porteur d’octets choisis. Toute distance réseau fonctionne, tant que le paquet atteint le client en démarrage.
3. Le chemin de réception transmet le message à PxeBcIcmpErrorDpcHandle en IPv4 ou à PxeBcIcmp6ErrorDpcHandle en IPv6, et la boucle de copie écrit au-delà du champ dans la mémoire adjacente.
4. L’état corrompu produit soit un blocage de démarrage déterministe, soit, pour un attaquant qui connaît la version du micrologiciel cible, la distribution d’octets fournis par l’attaquant, comme décrit plus loin.

Aucune preuve de concept publique n’existe, et aucune utilisation en conditions réelles n’a été signalée.

Comment se déroule l’attaque ?

Un seul message ICMP d’erreur surdimensionné, délivré pendant un démarrage réseau, suffit à corrompre l’environnement pré-OS.

Que peut faire un attaquant ?

L’avis décrit deux résultats, tous deux sans authentification et avant l’OS :

• Un blocage de démarrage déterministe. La corruption des données privées du pilote produit une exception CPU dans le cœur DXE au message ICMP d’erreur suivant, donc les machines échouent à démarrer depuis le réseau. Cela prive de provisioning et de récupération d’OS.
• L’exécution de code arbitraire dans l’environnement de démarrage. Un attaquant qui connaît la version du micrologiciel cible peut placer un événement contrefait dans le même paquet et faire distribuer par CoreSignalEvent() des octets fournis par l’attaquant en phase DXE. Le code s’exécute en ring 0, avant tout contrôle de sécurité de l’OS, et avant que Secure Boot ou le measured boot n’aient vérifié ou mesuré un composant d’OS.

L’avis exige que les erreurs ICMP atteignent la machine pendant le démarrage PXE ; il ne limite pas l’attaquant au réseau local. La joignabilité dépend du routage, des pare-feu et de l’isolation du réseau de provisioning.

Pourquoi le correctif fonctionne-t-il ?

Le commit 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec réécrit les deux boucles de copie avec une borne par fragment. Le gestionnaire IPv4 lit désormais :

  for (Index = 0, IcmpError = (UINT8 *)&Mode->IcmpError, CopiedLen = 0;
       (Index < RxData->FragmentCount) &&
       (CopiedLen < sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR));
       Index++, IcmpError += FragmentLen, CopiedLen += FragmentLen)
  {
    FragmentLen = MIN (
                    RxData->FragmentTable[Index].FragmentLength,
                    (UINT32)(sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR) - CopiedLen)
                    );
    CopyMem (IcmpError, RxData->FragmentTable[Index].FragmentBuffer, FragmentLen);
  }

Chaque itération copie au plus l’espace restant dans le champ. Elle avance le curseur de cette même longueur de fragment et s’arrête quand le champ est plein, donc aucune écriture ne peut dépasser la fin de Mode.IcmpError.

Le gestionnaire IPv6 a reçu le changement identique, et la requête de tirage fusionnée ajoute des tests de copie de fragments pour les deux chemins, plus un commit qui efface le tampon d’erreur ICMP avant de copier. Le correctif est complet pour le chemin de réception ICMP que l’avis nomme.

Le correctif a été fusionné dans EDK II master le 15 octobre 2026. Au 1er novembre, le dernier tag reste edk2-stable202608 et Debian liste les paquets ci-dessus comme non corrigés. Ces sources ne déterminent pas le statut de tous les micrologiciels : demandez confirmation au fournisseur.

Comment vérifier si j’ai été compromis ?

L’avis ne publie aucun indicateur de compromission. Le gestionnaire vulnérable s’exécute avant l’OS : ses journaux seuls ne permettent donc pas d’exclure une exploitation. Une tentative échouée peut ne laisser aucune trace utile sur l’hôte.

Le signal observable du chemin de déni de service se trouve dans les journaux du serveur de provisioning, pas dans la machine qui démarre :

# PXE boot requests seen by a dnsmasq or dhcpd provisioning server
grep -h "PXEClient" /var/log/syslog | tail -20

Traitez les blocages de démarrage inexpliqués sur les réseaux de provisioning comme une piste, pas une preuve : des problèmes réseau légitimes causent le même symptôme. Si votre modèle de menace inclut un attaquant durable sur un réseau de provisioning, faites pivoter les secrets que ces images de démarrage portent. Vérifiez l’intégrité des images hors bande après que le vendeur livre un micrologiciel corrigé.

Chronologie

• 2026-09-24 : TianoCore réserve CVE-2026-97631.
• 2026-09-28 : AMI ouvre une requête de tirage publique sur EDK II qui nomme le CVE et inclut un correctif, brisant le plan de divulgation des découvreurs prévu pour janvier, selon Ars Technica.
• 2026-10-15 : Le correctif retravaillé, requête de tirage 13302, est fusionné dans la branche master d’EDK II.
• 2026-10-22 : TianoCore publie l’avis GHSA-99cj-7hg9-mp4m et l’enregistrement CVE.
• 2026-10-27 : Ars Technica publie son analyse de la faille et de la divulgation.
• 2026-10-28 : L’avis atteint la liste de diffusion oss-security.
• 2026-10-30 : L’ADP de la CISA conclut à aucune exploitation connue.

L’embargo a été rompu 24 jours avant l’avis : la requête de tirage publique d’AMI est apparue le 28 septembre et TianoCore a publié le 22 octobre.

FAQ

Cela touche-t-il les machines qui démarrent depuis leur propre disque ?

Non. La faille vit dans le chemin de démarrage réseau du pilote PXE, donc une machine qui ne tente jamais un démarrage PXE n’ouvre jamais la fenêtre de réception. Le micrologiciel de serveur livre le PXE activé par défaut, donc inventoriez quelles machines démarrent réellement depuis le réseau.

Pourquoi Secure Boot ne stoppe-t-il pas cela ?

L’état corrompu et les octets distribués s’exécutent en phase DXE, avant le chargement du système d’exploitation. Secure Boot et le measured boot n’ont rien vérifié ni mesuré à ce stade. Les fonctions de sécurité du micrologiciel qui viennent plus tard dans le démarrage ne voient jamais le code de l’attaquant.

Y a-t-il une mise à jour de micrologiciel à installer ?

L’avis ne liste aucune version corrigée. Le correctif est dans EDK II master depuis le 15 octobre 2026, mais le dernier tag et les paquets Debian cités ne l’incluent pas au 1er novembre. Demandez au fournisseur si son micrologiciel intègre le correctif et appliquez sa mise à jour dès disponibilité.

Que faut-il à un attaquant pour l’exploiter ?

La joignabilité réseau de la machine en démarrage, un message ICMP d’erreur en unicast plus grand que le champ, et la connaissance de la version du micrologiciel cible. L’exploitation exige des adresses propres à la cible, donc chaque modèle, version et configuration demande son propre réglage, selon Eclypsium.

La faille est-elle exploitée en conditions réelles ?

L’ADP de la CISA a enregistré l’exploitation comme absente le 30 octobre 2026, et le CVE ne figure pas dans le flux KEV vérifié le 1er novembre. Les sources citées ne fournissent pas de preuve de concept publique ; cela n’exclut pas une exploitation non divulguée.

Pourquoi la divulgation a-t-elle lieu maintenant ?

Les découvreurs, Alex Matrosov d’Anthropic et Dan Holmes-Mitra de Google, avaient prévu la divulgation coordonnée pour janvier. AMI a ouvert une requête de tirage publique avec le correctif et l’identifiant CVE le 28 septembre 2026. Une fois cela porté à leur attention, TianoCore a publié l’avis, selon Ars Technica.

Références

• Avis GHSA-99cj-7hg9-mp4m, TianoCore, CVSS v4.0 9.5 : https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m (publié le 22 octobre 2026 ; vérifié le 1er novembre 2026)
• Enregistrement CVE-2026-97631, CNA TianoCore : https://www.cve.org/CVERecord?id=CVE-2026-97631 (vérifié le 1er novembre 2026)
• Commit de correctif 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec dans EDK II : https://github.com/tianocore/edk2/commit/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec (vérifié le 1er novembre 2026)
• Requête de tirage de correctif 13302 fusionnée : https://github.com/tianocore/edk2/pull/13302 (fusionnée le 15 octobre 2026 ; vérifiée le 1er novembre 2026)
• Requête de tirage 13200 d’AMI qui a rompu l’embargo : https://github.com/tianocore/edk2/pull/13200 (ouverte le 28 septembre 2026 ; vérifiée le 1er novembre 2026)
• Analyse d’Ars Technica sur la faille et la divulgation : https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ (publiée le 27 octobre 2026 ; vérifiée le 1er novembre 2026)
• Annonce oss-security : https://www.openwall.com/lists/oss-security/2026/10/28/4 (publiée le 28 octobre 2026 ; vérifiée le 1er novembre 2026)
• Suivi Debian pour CVE-2026-97631, paquets edk2 touchés et non corrigés : https://security-tracker.debian.org/tracker/CVE-2026-97631 (vérifié le 1er novembre 2026)
• Définition de EFI_PXE_BASE_CODE_ICMP_ERROR dans MdePkg au commit de correctif : https://github.com/tianocore/edk2/blob/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec/MdePkg/Include/Protocol/PxeBaseCode.h (vérifiée le 1er novembre 2026)
• Catalogue KEV de la CISA, flux vérifié pour CVE-2026-97631 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 1er novembre 2026)
• Versions EDK II: https://github.com/tianocore/edk2/releases