Un fallo sin parche en EDK II expone a los servidores que arrancan por red antes de Secure Boot

Un desbordamiento de búfer que lleva unos dieciséis años en el código de referencia de código abierto para UEFI puede bloquear un servidor mientras arranca desde la red y, en el peor de los casos, ejecutar código controlado por el atacante antes de que Secure Boot se haya inicializado. El fallo se identifica como CVE-2026-97631 y tiene una puntuación CVSS de 9,5. Reside en EDK II, la base de código de TianoCore sobre la que construyen casi todos los fabricantes de firmware. Existe una corrección en la rama principal de desarrollo del proyecto, pero a 28 de octubre de 2026 ninguna versión estable de EDK II la incluye, y la mayoría de los responsables de servidores todavía no tienen nada que instalar.

Qué ocurrió

EDK II incluye la pila de arranque por red PXE, que permite a una máquina obtener su imagen de inicio desde la red en lugar de un disco local. Mientras un arranque PXE está en curso, el controlador acepta mensajes de error ICMP y pequeñas respuestas de estado procedentes de la red y los copia en un búfer fijo de 504 bytes. Las comprobaciones de longitud alrededor de esa copia son incorrectas tanto en la ruta IPv4 como en la IPv6, por lo que un único mensaje manipulado de más de 504 bytes desborda el búfer y sobrescribe la memoria adyacente con datos elegidos por el atacante.

El bucle de copia defectuoso se remonta a un commit de noviembre de 2010. Todas las versiones de EDK II hasta edk2-stable202608 inclusive, la etiqueta estable actual de agosto de 2026, lo contienen. El arranque PXE viene activado por defecto en la compilación estándar de EDK II, y por eso hay tantos productos derivados afectados: los fabricantes independientes de BIOS AMI, Insyde y Phoenix, el fork endurecido Project Mu de Microsoft y los paquetes edk2 que distribuyen Red Hat Enterprise Linux 8, 9 y 10, SUSE y Debian, usados sobre todo como firmware UEFI para máquinas virtuales.

La divulgación no salió como estaba previsto. Se había programado una publicación coordinada para enero de 2027, pero un pull request abierto el 28 de septiembre de 2026 mencionó públicamente el CVE e incluyó el parche. TianoCore publicó entonces su aviso el 22 de octubre, con la corrección ya integrada en la rama principal desde el 15 de octubre. Microsoft reaccionó con rapidez y generó compilaciones de Project Mu con la corrección el 26 de octubre. En el lado del hardware, Intel afirma que no se conoce ningún producto comercial suyo bajo soporte de seguridad que esté afectado y que su propio código de referencia no incluye la funcionalidad vulnerable, aunque un fabricante de placas podría añadirla. Arm indica que el fallo no es directamente aplicable a su catálogo. AMD, AMI, Phoenix, Insyde, Microsoft y los grandes proveedores de nube no han confirmado públicamente el estado de su firmware, así que para muchos parques de servidores la respuesta honesta hoy es "desconocido".

Por qué importa

El peligro está en el momento. El código inyectado a través de este fallo se ejecuta dentro del firmware, antes de que Secure Boot, el arranque medido y cualquier control del sistema operativo hayan verificado nada. El atacante no necesita credenciales ni acceso previo a la máquina, solo poder alcanzarla en la red durante la breve ventana en la que arranca por PXE.

Las consecuencias se dividen en dos niveles. El sencillo es la denegación de servicio: el arranque se cuelga y la máquina no llega a iniciarse. Un parque que dependa de PXE para el aprovisionamiento o para nodos sin disco puede caer paquete a paquete. La ejecución de código es bastante más difícil y mucho menos fiable, porque la carga útil debe adaptarse a la compilación exacta del firmware. El código plantado de esta forma se ejecuta una sola vez y no persiste por sí mismo, pero una sola ejecución tan temprano en la cadena de arranque basta para instalar algo que sí persista, o para llegar a secretos que el proceso de arranque todavía conserva, como las claves de cifrado de disco liberadas por el TPM. En un escenario de robo o de acceso breve a la red, eso es una vía para romper el cifrado completo de disco en un servidor o un endpoint.

Hay dos matices importantes. Primero, no hay pruebas de explotación real: el CVE no figuraba en el catálogo Known Exploited Vulnerabilities de CISA en su actualización del 27 de octubre y nadie ha informado de haberlo visto en uso. Segundo, no es una puerta de entrada desde internet. Red Hat y SUSE valoran el vector de ataque como red adyacente, y el atacante realista es un empleado interno o alguien que ya tiene un punto de apoyo en un segmento local y quiere profundizar. Dicho esto, el parche ya es público, y cualquiera capaz de leer un diff puede deducir exactamente cómo se desencadena el desbordamiento.

Tampoco es la primera vez que la pila PXE deja en evidencia a EDK II. El conjunto de nueve fallos PixieFail, divulgado en enero de 2024, afectó al mismo componente, y las campañas de fuzzing que siguieron no detectaron este.

Qué hacer

• Inventaríe lo que arranca por red. Los hosts de aprovisionamiento bare-metal, los nodos de cómputo sin disco, los clientes ligeros y las máquinas virtuales con firmware basado en EDK II entran todos en esta categoría. Si no puede enumerarlos, no puede protegerlos.
• Desactive PXE donde no haga falta. Viene activado por defecto en la mayoría de las compilaciones. Apagar el arranque por red en la configuración del firmware elimina por completo la superficie de ataque en las máquinas que solo arrancan desde disco local.
• Aísle la red de arranque. Mantenga el aprovisionamiento en una VLAN dedicada, restrinja qué hosts pueden enviar ICMP hacia las máquinas que arrancan y nunca haga arranque PXE a través de un segmento al que puedan llegar dispositivos no confiables.
• Vigile el tráfico durante el arranque. Los mensajes de error ICMP sobredimensionados dirigidos a clientes PXE y los arranques que se cuelgan sin explicación son las señales sobre las que alertar hasta que se actualice el firmware.
• Siga a sus proveedores. No existe una mitigación oficial. La corrección es un cambio de código sencillo que no requiere revocar certificados ni claves, a diferencia de BootHole o BlackLotus, así que las actualizaciones de BIOS y UEFI de los fabricantes deberían ser más fáciles de desplegar cuando aparezcan. Actualice los paquetes edk2 de las distribuciones en cuanto se publiquen y priorice los hosts de virtualización donde las máquinas virtuales arrancan por PXE.

Un fallo así solo importa si un atacante puede llegar realmente a sus hosts mientras arrancan, y esa es una pregunta sobre su red, no sobre su firmware. Una prueba de penetración interna realizada por el equipo de 4tify la responde directamente: qué segmentos transportan tráfico de arranque, qué puede ver una estación comprometida durante una ventana de aprovisionamiento y si los controles anteriores resisten en la práctica.