Un fallo en el código que arranca la mayoría de los servidores del mundo ha salido a la luz antes de tiempo. Se trata de la vulnerabilidad CVE-2026-97631, un desbordamiento de búfer en EDK II, el proyecto de código abierto que sirve de base al firmware UEFI de buena parte de la industria. Su gravedad es de 9,5 sobre 10 y permite ejecutar código antes de que se cargue el sistema operativo, es decir, antes de que entren en juego defensas como el arranque seguro (Secure Boot).
El problema no afecta a cualquiera: solo es explotable mientras el equipo arranca por red. Pero en centros de datos y empresas que despliegan servidores de esa forma, el riesgo es real, y el parche ya es público mientras los fabricantes todavía no han distribuido actualizaciones.
Qué es EDK II y por qué afecta a tanta gente
EDK II (o EDK2) es la implementación de referencia de UEFI que mantiene el proyecto TianoCore. UEFI es el firmware que se ejecuta nada más encender el ordenador, el sucesor de la antigua BIOS. Según Ars Technica, prácticamente todos los proveedores de firmware, como AMI, Insyde o Phoenix, usan ese código de forma extensa, y Project Mu, la variante reforzada de Microsoft, también incluía el componente vulnerable.
Por eso el medio estadounidense habla de un fallo que alcanza a la mayoría de los servidores del planeta. Conviene matizarlo: el aviso oficial no da ninguna cifra de equipos afectados, y cada fabricante decide si incluye ese código y si deja activo el arranque por red.
Cómo funciona el fallo
El error está en el controlador PXE de EDK II, la pieza que permite que un equipo arranque descargando su sistema desde la red local. Durante ese proceso, el controlador escucha mensajes de error ICMP y los copia en un campo fijo de 504 bytes. El aviso de seguridad de TianoCore explica que la copia calcula mal los límites, tanto en IPv4 como en IPv6, de modo que un mensaje más largo escribe datos del atacante más allá de ese espacio.
El aviso describe dos consecuencias. La más sencilla es bloquear el arranque del equipo. La más grave exige conocer la versión exacta del firmware del objetivo: en ese caso, el atacante puede hacer que se ejecute su propio código en una fase en la que todavía no existe ningún control de seguridad del sistema operativo. Según Ars Technica, el fallo lleva unos 16 años en el código.
Una divulgación que se torció
Lo descubrieron Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, que habían pactado mantenerlo en secreto hasta una divulgación coordinada prevista para enero. Según Ars Technica, el calendario se rompió cuando AMI publicó el mes pasado una propuesta de cambio en el repositorio que detallaba el fallo y su corrección. TianoCore publicó entonces su aviso, el 22 de octubre.
Con el arreglo a la vista de todos, resulta mucho más fácil entender cómo provocar el fallo y crear ataques. Es el segundo caso en pocos días de una divulgación fallida con un error crítico, después del que afectó al lenguaje PHP.
Límites importantes para el atacante
No basta con enviar un paquete desde cualquier lugar. El atacante tiene que hacer llegar el mensaje justo mientras el equipo arranca por red, y en la práctica eso suele requerir cierto acceso a la red interna. Jesse Michael, investigador de la empresa de seguridad Eclypsium, explicó a Ars Technica que el ataque hay que ajustarlo a cada modelo, versión y configuración, porque las direcciones de memoria cambian. HD Moore, creador de Metasploit, advirtió en cambio que podría servir para romper el cifrado de disco si alguien logra acceso breve a la red o roba el equipo.
Los usuarios domésticos y las pequeñas oficinas que arrancan desde su disco no están expuestos por esta vía. Intel afirma que ninguno de sus productos comerciales con soporte de seguridad está afectado, aunque recuerda que los fabricantes de placas pueden integrar ese código. Arm asegura que el fallo no afecta directamente a su catálogo.
Parche en el código, pero no en las máquinas
La corrección se incorporó a la rama principal de EDK II el 15 de octubre, pero, según Severity Daily, ninguna versión estable del proyecto la incluye todavía: la última es de agosto y la siguiente se espera hacia noviembre. Después, cada fabricante tendrá que probarla y publicar su actualización de firmware.
Mientras tanto, la recomendación es preguntar al proveedor del firmware si sus equipos están afectados, desactivar el arranque por red siempre que sea posible y vigilar los registros por si aparecen intentos de explotación.
