RCE en el controlador PXE de EDK II antes de Secure Boot (CVE-2026-97631)

TL;DR

• Mientras una máquina arranca por PXE sobre IPv4 o IPv6, un atacante de red sin autenticar puede enviar un mensaje ICMP de error sobredimensionado que corrompe la memoria del entorno de arranque UEFI. La corrupción ejecuta bytes elegidos por el atacante antes de que se cargue el sistema operativo. TianoCore publicó el aviso GHSA-99cj-7hg9-mp4m el 22 de octubre de 2026.
• La exposición es cualquier firmware basado en EDK II que arranque por red, con el listener PXE alcanzable por el atacante durante la ventana de arranque. El impacto ocurre antes de que Secure Boot o el measured boot hayan verificado o medido cualquier componente del sistema operativo, por lo que esas defensas no se aplican.
• El registro CVE de TianoCore lo clasifica como crítico, CVSS v4.0 9.5. El ADP de CISA registró la explotación como ninguna el 30 de octubre de 2026, y el CVE no aparece en el flujo KEV comprobado el 1 de noviembre. Las fuentes citadas no proporcionan una prueba de concepto pública; esto no descarta una explotación no divulgada.
• El aviso no lista ninguna versión corregida. Aísle las redes PXE y de aprovisionamiento del tráfico no confiable, desactive el arranque por red innecesario y consulte si el firmware de su proveedor incluye la corrección.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• El firmware de la máquina incluye el controlador PXE Base Code vulnerable de EDK II o un derivado.
• El arranque PXE está activado y la máquina arranca o intenta arrancar desde la red por IPv4 o IPv6.
• Un atacante puede entregar un mensaje ICMP de error unidifusión a la dirección IP de la máquina durante esa ventana de arranque, desde cualquier distancia de red.

Las máquinas que arrancan únicamente desde un disco local no están expuestas. La vulnerabilidad está en la propia ruta de arranque por red.

Los paquetes Debian anteriores siguen siendo vulnerables; compruebe cada firmware con su proveedor. Identifique su firmware y compruebe si arranca por red:

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

El arranque PXE se configura en el firmware; inventaríelo por servidor o con herramientas de aprovisionamiento. Consulte al fabricante si el firmware instalado incluye el controlador vulnerable y su corrección.

¿Cómo lo corrijo?

El aviso no lista ninguna versión corregida. Hasta que su proveedor confirme un firmware corregido, reduzca la exposición:

1. Aísle las VLAN de PXE y aprovisionamiento de redes no confiables para restringir la entrega de mensajes ICMP maliciosos durante el arranque por red.
2. Desactive el arranque PXE y por red en toda máquina que no lo necesite, lo que elimina por completo el listener vulnerable.
3. Pregunte a su proveedor de servidores por su plan de firmware y aplique la actualización cuando salga. La corrección necesita un cambio de código básico y una actualización de firmware, sin revocaciones de claves ni gestión de certificados, según la evaluación de Eclypsium citada por Ars Technica.

Los límites son claros. El aislamiento reduce quién puede alcanzar una máquina mientras arranca; no corrige el controlador. Desactivar el arranque por red elimina la exposición solo en las máquinas que nunca lo necesitan. Nada por debajo de la capa de red detiene el propio desbordamiento hasta que se ejecute una imagen de firmware corregida.

¿Cuál es la causa raíz?

El controlador PXE copia cada mensaje ICMP de error recibido en un campo de tamaño fijo sin un límite funcional. El bucle luego avanza el puntero de destino más allá de ese campo.

Durante el arranque por red, el controlador PXE Base Code de NetworkPkg/UefiPxeBcDxe mantiene abierta una solicitud de recepción para mensajes ICMP de error. Copia cada mensaje en el campo fijo EFI_PXE_BASE_CODE_ICMP_ERROR, Mode.IcmpError, de su estructura de estado: una unión de cabecera ICMP de 8 bytes seguida de una matriz de datos de 494 bytes.

El campo se define en 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;

El bucle de copia en PxeBcSupport.c manejaba los fragmentos del mensaje recibido, tanto en el gestor IPv4 como en el IPv6, así antes de la corrección:

  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;
  }

Dos defectos invalidan el límite. Cuando la longitud acumulada supera el campo, la rama else copia la longitud excedente en lugar de la capacidad restante. Según los fragmentos, esa escritura puede superar el campo de destino.

El bucle también avanza IcmpError en CopiedLen, el total acumulado, en lugar de la longitud del fragmento actual, así que el cursor de escritura se desvía más allá de los límites con cada fragmento. Nada antes en la ruta de recepción limita la longitud del mensaje. Un solo mensaje ICMP de error sobredimensionado escribe por tanto bytes controlados por el atacante más allá de Mode.IcmpError, en los datos adyacentes del controlador.

¿Cómo se explota?

El ataque es un paquete unidifusión durante una ventana de arranque, según el aviso:

1. La máquina entra en un arranque PXE por IPv4 o IPv6, y la solicitud de recepción de mensajes ICMP de error del controlador se activa.
2. El atacante envía un mensaje ICMP de error unidifusión dirigido a la dirección IP de la máquina, más grande que el campo IcmpError y con bytes elegidos. Cualquier distancia de red sirve, siempre que el paquete alcance al cliente que arranca.
3. La ruta de recepción pasa el mensaje a PxeBcIcmpErrorDpcHandle en IPv4 o a PxeBcIcmp6ErrorDpcHandle en IPv6, y el bucle de copia escribe más allá del campo en la memoria adyacente.
4. El estado corrompido produce un bloqueo determinista del arranque o, para un atacante que conoce la versión del firmware objetivo, la ejecución de bytes suministrados por el atacante, como se describe más abajo.

El ADP de CISA registró la explotación como ninguna el 30 de octubre de 2026, y el CVE no aparece en el flujo KEV comprobado el 1 de noviembre. Las fuentes citadas no proporcionan una prueba de concepto pública; esto no descarta una explotación no divulgada.

¿Cómo fluye el ataque?

Un solo mensaje ICMP de error sobredimensionado, entregado durante un arranque por red, basta para corromper el entorno previo al sistema operativo.

¿Qué puede hacer un atacante?

El aviso describe dos resultados, ambos sin autenticación y previos al sistema operativo:

• Un bloqueo determinista del arranque. La corrupción de los datos privados del controlador produce una excepción de CPU dentro del núcleo DXE en el siguiente mensaje ICMP de error, así que las máquinas fallan al arrancar desde la red. Eso deniega el aprovisionamiento y la recuperación del sistema operativo.
• Ejecución de código arbitrario en el entorno de arranque. Un atacante que conoce la versión del firmware objetivo puede colocar un evento falsificado en el mismo paquete y lograr que CoreSignalEvent() distribuya bytes suministrados por el atacante en la fase DXE. El código se ejecuta en ring 0, antes de que exista cualquier control de seguridad del sistema operativo, y antes de que Secure Boot o el measured boot hayan verificado o medido cualquier componente del sistema operativo.

El aviso exige entregar errores ICMP durante el arranque PXE; no limita al atacante a la red local. La accesibilidad depende del enrutamiento, los cortafuegos y el aislamiento de la red de aprovisionamiento.

¿Por qué funciona la corrección?

El commit 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec reescribe ambos bucles de copia con un límite por fragmento. El gestor IPv4 queda así:

  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);
  }

Cada iteración copia como máximo el espacio que queda en el campo. Avanza el cursor esa misma longitud de fragmento y se detiene cuando el campo está lleno, así que ninguna escritura puede pasar del final de Mode.IcmpError.

El gestor IPv6 recibió el cambio idéntico, y la solicitud de extracción fusionada añade pruebas de copia de fragmentos para ambas rutas, más un commit que limpia el búfer de error ICMP antes de copiar. La corrección es completa para la ruta de recepción ICMP que el aviso nombra.

La corrección se fusionó en EDK II master el 15 de octubre de 2026. Al 1 de noviembre, la última versión etiquetada sigue siendo edk2-stable202608 y Debian lista los paquetes anteriores sin corregir. Estas fuentes no establecen el estado de todos los firmwares; solicite confirmación a su proveedor.

¿Cómo compruebo si he sido comprometido?

El aviso no publica indicadores de compromiso. Como el gestor vulnerable se ejecuta antes del sistema operativo, los registros del SO por sí solos no descartan una explotación. Un intento fallido puede no dejar registros útiles en el equipo.

La señal observable de la vía de denegación de servicio está en los registros del servidor de aprovisionamiento, no en la máquina que arranca:

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

Trate los bloqueos de arranque inexplicables en redes de aprovisionamiento como una pista, no como una prueba: problemas de red legítimos causan el mismo síntoma. Si su modelo de amenazas incluye un atacante persistente en una red de aprovisionamiento, rote los secretos que transportan esas imágenes de arranque. Verifique la integridad de las imágenes fuera de banda después de que el proveedor entregue el firmware corregido.

Cronología

• 2026-09-24: TianoCore reserva CVE-2026-97631.
• 2026-09-28: AMI abre una solicitud de extracción pública en EDK II que nombra el CVE e incluye una corrección, rompiendo el plan de divulgación de los descubridores previsto para enero, según Ars Technica.
• 2026-10-15: La corrección reelaborada, solicitud de extracción 13302, se fusiona en la rama master de EDK II.
• 2026-10-22: TianoCore publica el aviso GHSA-99cj-7hg9-mp4m y el registro CVE.
• 2026-10-27: Ars Technica publica su análisis de la falla y de la divulgación.
• 2026-10-28: El aviso llega a la lista de correo oss-security.
• 2026-10-30: El ADP de CISA registra que no se conoce explotación.

El embargo se rompió 24 días antes del aviso: la solicitud de extracción pública de AMI apareció el 28 de septiembre y TianoCore publicó el 22 de octubre.

Preguntas frecuentes

¿Afecta a las máquinas que arrancan desde su propio disco?

No. La falla está en la ruta de arranque por red del controlador PXE; una máquina que nunca intenta arrancar por PXE no abre esa ventana de recepción. Compruebe el comportamiento real y la configuración del firmware.

¿Por qué Secure Boot no detiene esto?

El estado corrompido y los bytes distribuidos se ejecutan en la fase DXE, antes de que se cargue el sistema operativo. Secure Boot y el measured boot no han verificado ni medido ningún componente del sistema operativo en ese punto. Las funciones de seguridad del firmware que llegan más tarde en el arranque nunca ven el código del atacante.

¿Hay alguna actualización de firmware para instalar?

El aviso no lista ninguna versión corregida. La corrección está en EDK II master desde el 15 de octubre de 2026, pero la última etiqueta y los paquetes Debian citados no la incluyen al 1 de noviembre. Consulte a su proveedor y aplique su actualización cuando esté disponible.

¿Qué necesita un atacante para explotarla?

Alcance de red hacia la máquina que arranca, un mensaje ICMP de error unidifusión más grande que el campo, y conocimiento de la versión del firmware objetivo. La explotación requiere direcciones específicas del objetivo, así que cada modelo, versión y configuración necesita su propio ajuste, según Eclypsium.

¿Se explota en el mundo real?

El ADP de CISA registró la explotación como ninguna el 30 de octubre de 2026, y el CVE no aparece en el flujo KEV comprobado el 1 de noviembre. Las fuentes citadas no proporcionan una prueba de concepto pública; esto no descarta una explotación no divulgada.

¿Por qué la divulgación ocurre ahora?

Los descubridores, Alex Matrosov de Anthropic y Dan Holmes-Mitra de Google, habían previsto la divulgación coordinada para enero. AMI abrió una solicitud de extracción pública con la corrección y el identificador CVE el 28 de septiembre de 2026. Cuando eso llegó a su atención, TianoCore publicó el aviso, según Ars Technica.

Referencias

• Aviso GHSA-99cj-7hg9-mp4m, TianoCore, CVSS v4.0 9.5: https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m (publicado el 22 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Registro CVE-2026-97631, CNA TianoCore: https://www.cve.org/CVERecord?id=CVE-2026-97631 (comprobado el 1 de noviembre de 2026)
• Commit de corrección 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec en EDK II: https://github.com/tianocore/edk2/commit/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec (comprobado el 1 de noviembre de 2026)
• Solicitud de extracción de corrección 13302 fusionada: https://github.com/tianocore/edk2/pull/13302 (fusionada el 15 de octubre de 2026; comprobada el 1 de noviembre de 2026)
• Solicitud de extracción 13200 de AMI que rompió el embargo: https://github.com/tianocore/edk2/pull/13200 (abierta el 28 de septiembre de 2026; comprobada el 1 de noviembre de 2026)
• Análisis de Ars Technica sobre la falla y la divulgación: https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ (publicado el 27 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Anuncio en oss-security: https://www.openwall.com/lists/oss-security/2026/10/28/4 (publicado el 28 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Rastreador de Debian para CVE-2026-97631, paquetes edk2 vulnerables y sin corregir: https://security-tracker.debian.org/tracker/CVE-2026-97631 (comprobado el 1 de noviembre de 2026)
• Definición de EFI_PXE_BASE_CODE_ICMP_ERROR en MdePkg en el commit de corrección: https://github.com/tianocore/edk2/blob/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec/MdePkg/Include/Protocol/PxeBaseCode.h (comprobada el 1 de noviembre de 2026)
• Catálogo KEV de CISA, canal verificado para CVE-2026-97631: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 1 de noviembre de 2026)
• Versiones de EDK II: https://github.com/tianocore/edk2/releases