Un fallo crítico en el firmware UEFI EDK II permite ejecutar código antes del arranque y amenaza a la mayoría de los servidores

Un fallo crítico en EDK II, el código abierto de firmware UEFI sobre el que se construyen la mayoría de los servidores del mundo, permite a un atacante de red ejecutar código antes de que el sistema operativo arranque. El aviso lo publicó TianoCore, el proyecto que mantiene EDK II, y Ars Technica lo llevó este martes a su portada de seguridad: la vulnerabilidad, CVE-2026-97631, tiene una puntuación de 9,5 sobre 10.

El problema está en el controlador de arranque por red PXE: sus gestores de errores ICMP, en IPv4 e IPv6, copian los mensajes entrantes en un campo fijo de 504 bytes con un cálculo de tamaño incorrecto. Un mensaje más largo desborda ese espacio y escribe fuera de sus límites. Según el aviso, la corrupción es determinista y, como mínimo, cuelga el arranque; un atacante que conozca el firmware concreto puede llegar a ejecutar código arbitrario en la fase DXE, con privilegios de anillo 0.

Ese momento es el peor posible: el código se ejecutaría antes que Secure Boot, que establece la cadena de confianza de todo lo que viene después, y antes de que las protecciones basadas en TPM puedan actuar, con la posibilidad de instalar cargas que se activen al principio de cada arranque. El alcance viene de la reutilización: proveedores de firmware como AMI, Insyde y Phoenix construyen sobre EDK II, y el propio Microsoft lo usa como base de su Project Mu.

Hay condiciones que acotan el riesgo. La máquina tiene que estar arrancando por red en ese momento y el atacante necesita acceso a la red local: el fallo no da, por sí solo, una entrada desde internet. El número de sistemas vulnerables se desconoce y, según Ars Technica, no hay evidencia de explotación hasta hoy. Intel ha dicho que ninguno de sus productos comerciales en soporte se cree afectado, porque esa función no está en su código de referencia, aunque un fabricante podría haberla integrado.

El arreglo ya existe en el código de TianoCore —una corrección fusionada a mediados de octubre añade controles de límites—, pero tiene que llegar a cada máquina a través de su proveedor de firmware, y registros como el de Debian seguían marcando el paquete como vulnerable este martes. Para quien administra servidores con arranque PXE, la tarea inmediata es vigilar las actualizaciones de BIOS de su proveedor y valorar desactivar el arranque por red donde no sea imprescindible.