EDK2 UEFI: fallo CVE-2026-97631 en el arranque PXE de servidores

Ya es pública una vulnerabilidad crítica, CVE-2026-97631 (puntuación 9.5 sobre 10), en TianoCore EDK II (EDK2), el código open source de referencia con el que fabricantes de hardware y proveedores cloud construyen el firmware UEFI que arranca los servidores. El fallo está en el driver que gestiona el arranque desde la red (PXE) y permite ejecutar código antes de que se cargue el sistema operativo y antes de que Secure Boot verifique cualquier componente.

Las fuentes analizadas son Ars Technica (republicado íntegramente por Wired) y Security Affairs, que cita el aviso oficial del proyecto; de The Hacker News solo tenemos el titular, que confirma los puntos principales.

Una divulgación que llegó antes de tiempo

El fallo lo descubrieron investigadores de Anthropic y de Google, que habían acordado una divulgación coordinada para enero. Según Ars Technica, en septiembre AMI publicó una pull request que describía el defecto e incluía la corrección; cuando los investigadores se dieron cuenta, el proyecto TianoCore difundió el aviso público. Con el parche a la vista, reconstruir el mecanismo de ataque resulta mucho más sencillo para quien tiene los conocimientos, mientras que distribuir las actualizaciones de firmware en millones de máquinas llevará tiempo.

Detalles técnicos

El defecto tiene unos 16 años y se encuentra en el driver PXE Base Code (NetworkPkg/UefiPxeBcDxe). Durante el arranque desde la red, el driver mantiene abierta una recepción para los mensajes ICMP de error y copia cada mensaje en un campo fijo de 504 bytes, Mode.IcmpError. Según el aviso, en los manejadores IPv4 e IPv6 (PxeBcIcmpErrorDpcHandle y PxeBcIcmp6ErrorDpcHandle) el control de límites es incorrecto:

• un mensaje de más de 504 bytes se copia igualmente;
• el puntero de destino avanza según la longitud acumulada y no la de cada fragmento;
• ningún control previo limita la longitud del mensaje.

El resultado es una escritura de bytes elegidos por el atacante más allá del campo, en la memoria de la fase DXE del firmware. El aviso clasifica el problema como Out-of-bounds Write, Classic Buffer Overflow e Incorrect Calculation of Buffer Size, con impacto en confidencialidad, integridad y disponibilidad.

Cómo se explota

• El mensaje malicioso es un simple unicast a la dirección IP del dispositivo, enviado mientras está en curso el arranque PXE, por IPv4 o IPv6, sin autenticación.
• Con datos no válidos el arranque se bloquea (DoS).
• Si conoce la build exacta del firmware, el atacante puede hacer que se ejecute su propio código en el entorno UEFI, en ring 0, eludiendo también la atestación que debería demostrar a servidores remotos que la máquina está íntegra.
• El código no es persistente, pero puede servir para instalar otros componentes que se ejecutan en cada arranque.

HD Moore (Dragos), citado por Ars Technica, señala que en ese momento el proceso de arranque aún tiene acceso a componentes como el TPM: con un acceso breve a la red, o con un dispositivo robado, se podría llegar a romper el cifrado del disco.

Los límites

• Hace falta cierto control de la red local: es un escenario de insider o de atacante que ya ha entrado y busca elevar privilegios. Las fuentes coinciden en que no hay pruebas de que el fallo sirva como acceso inicial.
• Según Jesse Michael (Eclypsium), el exploit debe adaptarse a cada modelo, versión y configuración, porque las direcciones de memoria cambian.
• Ninguna fuente señala exploits públicos ni explotación en curso.

Como técnicas MITRE ATT&CK pertinentes (clasificación nuestra) se pueden indicar T1542 Pre-OS Boot (en particular T1542.001, System Firmware) y T1068 Exploitation for Privilege Escalation.

A quién afecta

Están expuestos los sistemas con firmware basado en EDK2 que arrancan desde la red con PXE, función que según Ars Technica está activada por defecto. No se ven afectados los dispositivos domésticos y de pequeñas oficinas ni quien arranca solo desde disco.

El alcance exacto aún no está claro:

• AMI, Insyde y Phoenix usan ampliamente EDK2, y también Project Mu de Microsoft contenía el componente vulnerable;
• Intel declara que ninguno de sus productos comerciales aún con soporte de seguridad consta como afectado, pero que un fabricante de placas o de sistemas puede haber integrado la función;
• Arm afirma que la CVE «no es directamente aplicable» a sus productos;
• AMD, Phoenix, AMI, Microsoft y Amazon no habían respondido a las preguntas de Ars Technica en el momento de la publicación.

Las fuentes no hablan de máquinas virtuales: muchas plataformas de virtualización usan firmware UEFI derivado de EDK2, así que conviene preguntar también a los proveedores de hipervisores y cloud si las VM con arranque desde la red están implicadas.

Impacto para las empresas europeas e italianas

El arranque PXE es habitual en los centros de datos, en el aprovisionamiento automático de servidores y en la distribución de imágenes de sistema. Para las entidades sujetas a NIS2, en particular proveedores de servicios digitales, centros de datos y cloud, el fallo entra en la gestión de vulnerabilidades y en la seguridad de la cadena de suministro: hace falta un inventario de firmware y una solicitud formal a los proveedores. En la sanidad, donde servidores y puestos de trabajo se preparan a menudo desde la red, hay que revisar también los entornos de aprovisionamiento. Dada su difusión, HD Moore considera probable que el fallo perdure mucho tiempo en sistemas sin soporte.

Qué hacer ya

1. Haz el inventario de los sistemas que arrancan desde la red y de su firmware (fabricante, modelo, versión de BIOS/UEFI).
2. Pregunta a los fabricantes de servidores y firmware si están afectados y cuándo llegará la actualización. Según Eclypsium la corrección es una actualización normal de BIOS/UEFI: no hacen falta revocaciones ni actualizaciones de las claves de Secure Boot (PK, KEK, db, dbx).
3. Desactiva el arranque PXE donde no sea necesario, al menos temporalmente, como sugieren las fuentes.
4. Donde sea necesario, aísla las redes de aprovisionamiento en segmentos dedicados y limita quién puede enviar tráfico a las máquinas en arranque (indicación general nuestra).
5. Mantén activos TPM y Secure Boot: siguen siendo útiles, aunque no detengan este ataque.
6. Revisa los logs de red en busca de intentos de explotación, por ejemplo mensajes ICMP de error inusualmente largos o fragmentados hacia máquinas en arranque PXE.

Cómo ayuda ARXDOME

ARX Sentry recoge el inventario de hardware y sistema de las máquinas con el agente, un punto de partida para saber qué servidores verificar con los fabricantes. ARX Watch escucha la red con las sondas ya instaladas y muestra también los dispositivos sin agente, útil para no olvidar máquinas en los segmentos de aprovisionamiento. Los logs de los firewalls recogidos por ARX Sentry llegan a las páginas SOC, donde puedes examinar los eventos que afectan a estos segmentos.

Última actualización: 28 de octubre de 2026