Una vulnerabilidad crítica ha permanecido oculta durante 16 años en EDK II, el código abierto que la mayoría de los fabricantes de hardware utiliza para construir firmware UEFI. La falla permite a un atacante ejecutar código en una máquina antes de que se cargue el sistema operativo, aunque solo mientras el equipo arranca a través de la red.
El firmware UEFI es el software que se ejecuta primero al encender un ordenador, antes del sistema operativo. Un atacante que pueda alcanzar la máquina con un mensaje de red manipulado durante ese arranque por red puede bloquear el proceso o, con un trabajo adaptado a la compilación exacta del firmware, ejecutar su propio código antes de que se carguen Secure Boot y otras defensas de inicio.
El atacante no necesita contraseña ni acceso previo al equipo, pero sí debe alcanzarlo por la red durante la breve ventana en la que está arrancando de esta forma. Red Hat y SUSE, que distribuyen el código afectado, calificaron la falla como explotable desde una posición de red adyacente, no a través de internet abierta.
TianoCore, el proyecto detrás de EDK II, publicó un aviso el 22 de octubre y otorgó a la falla, registrada como CVE-2026-97631, una puntuación de 9.5 sobre 10. Existe una corrección en el código, pero ninguna versión estable de EDK II la incorpora todavía, y el aviso sigue sin indicar una versión parcheada, por lo que la mayoría de los usuarios no tiene nada que instalar por ahora.
Qué permite hacer la falla
La vulnerabilidad es un desbordamiento de búfer en el código de arranque por red de EDK II, conocido como PXE. Durante un arranque PXE, una máquina carga su imagen de inicio desde la red en lugar de un disco local.
Como parte de este proceso, el controlador PXE escucha mensajes de error ICMP y los pequeños mensajes de estado que devuelven los dispositivos de red, y copia cada uno en un área fija de 504 bytes de memoria. Las comprobaciones de tamaño en esa copia son incorrectas tanto en la versión IPv4 como en la IPv6 del código, por lo que un mensaje de más de 504 bytes desborda el área y sobrescribe memoria cercana con datos elegidos por el atacante.
Para desencadenar el fallo, el atacante solo tiene que enviar un mensaje de error manipulado a la dirección de la máquina mientras esta se encuentra en medio de un arranque por red. No se necesita contraseña ni acceso previo al equipo.
El resultado simple es un bloqueo: el arranque se cuelga y la máquina no logra iniciar. Conseguir que se ejecute código es mucho más difícil y bastante menos fiable. El aviso indica que un atacante que conozca la compilación exacta del firmware puede plantar un "evento falsificado" que haga que el firmware ejecute su propio código, por lo que un exploit debe construirse para una compilación específica.
Cuando se ejecuta código, lo hace dentro del firmware, antes de que Secure Boot y otras comprobaciones de arranque hayan verificado nada. Ese momento es lo que hace grave la falla. El código plantado de esta forma se ejecuta una sola vez y no sobrevive por sí mismo a un reinicio, pero esa única ejecución basta para instalar otro código que sí se inicie en cada arranque.
Quién está afectado
El error está en EDK II hasta la versión edk2-stable202608 inclusive, la más reciente, fechada el 21 de agosto. EDK II es el código de referencia sobre el que construyen casi todos los fabricantes de firmware UEFI, incluidos los creadores independientes de BIOS AMI, Insyde y Phoenix, así como la bifurcación reforzada de Microsoft, Project Mu.
El bucle de copia defectuoso está en el código desde un commit añadido en noviembre de 2010, según descubrió The Hacker News al rastrear el historial del proyecto. El arranque por red PXE está activado por defecto en la compilación estándar de EDK II.
La falla no afecta a usuarios domésticos o de oficina que solo arrancan desde un disco local. Se aplica a organizaciones cuyas máquinas arrancan por red, principalmente servidores y equipos de centros de datos.
Se desconoce cuántos productos en circulación llevan el código vulnerable. Intel dijo a Ars Technica que no tiene conocimiento de que ninguno de sus "productos comerciales actualmente bajo soporte de seguridad" esté afectado, y que "no incluye la funcionalidad EDK2 afectada en su código de referencia", aunque un fabricante de placas OEM o un integrador de sistemas podría añadirla. Arm afirmó que la falla "no es directamente aplicable a la cartera de productos de Arm". El firmware propio de ambas compañías se basa en EDK II.
Las distribuciones de Linux también distribuyen el código. Red Hat incluye su paquete edk2 en Red Hat Enterprise Linux 8, 9 y 10 como afectado y aún sin corregir, y SUSE y Debian marcan sus paquetes equivalentes de la misma manera.
AMD, Phoenix Technologies, AMI, Microsoft y Amazon no respondieron a las preguntas del sitio de noticias tecnológicas antes de la publicación, y TianoCore tampoco lo hizo, por lo que el estado de sus productos sigue sin estar claro.
¿Existe una solución?
Se ha fusionado una corrección en el código fuente de EDK II. Reescribe la copia defectuosa para que un mensaje demasiado grande se trunque en 504 bytes en lugar de desbordarse, y llegó a la rama principal de desarrollo el 15 de octubre.
Ninguna versión estable de EDK II incluye esa corrección todavía. The Hacker News revisó las etiquetas de lanzamiento del proyecto el 28 de octubre y comprobó que la más reciente, edk2-stable202608, es anterior a ella, y el aviso sigue indicando la versión parcheada como "Not patched currently" (no parcheada actualmente). Project Mu de Microsoft ya ha incorporado la corrección a sus ramas de lanzamiento y publicó compilaciones etiquetadas el 26 de octubre.
Incluso con la corrección pública en el código fuente, un operador de servidores no tiene nada que instalar hasta que el fabricante de su firmware publique una actualización de BIOS o UEFI construida a partir de ella. Ese paso es al menos sencillo, según declaró a Ars Technica Jesse Michael, investigador principal de la empresa de seguridad de firmware Eclypsium: a diferencia de los bypass de Secure Boot como BootHole y BlackLotus, la falla "puede corregirse con una corrección de código básica" y no requiere revocaciones de certificados ni claves.
Hasta que llegue esa actualización, el aviso no enumera ningún workaround. Dado que la falla solo es alcanzable durante un arranque por red, los operadores que no necesiten PXE pueden desactivarlo para reducir la exposición. Ars también aconsejó vigilar el tráfico de red y los registros durante el arranque en busca de indicios de intentos.
Cómo se hizo público
La falla fue encontrada por Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, según acredita el aviso. Se había planificado una divulgación coordinada para enero de 2027.
Ese plan se vio superado el 28 de septiembre, cuando una solicitud de incorporación (pull request) a EDK II, firmada por un ingeniero de AMI, describió públicamente la falla por su número CVE e incluyó la corrección. Cuando los descubridores vieron la publicación, TianoCore emitió su aviso el 22 de octubre, semanas antes de la fecha prevista. Con el parche público, Ars señaló que atacantes capacitados pueden estudiarlo para determinar cómo se desencadena la falla y construir exploits funcionales.
No hay indicios de que la falla se haya utilizado en un ataque. No aparecía en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA en su actualización del 27 de octubre, y ningún investigador ha informado de haberla visto explotada.
La falla tampoco constituye por sí sola una vía de entrada a una red, informó Ars Technica tras consultar a varios investigadores de firmware. El atacante realista es un insider, o alguien que ya ha obtenido una posición de bajo nivel en la red local y quiere profundizar.
"Un atacante que pretenda comprometer un endpoint o servidor cercano podría usar este error para secuestrar el flujo del programa en un punto en el que el proceso de arranque todavía tiene acceso a componentes sensibles, como el TPM del endpoint", dijo HD Moore, creador de Metasploit y director de investigación de la empresa de seguridad Dragos, en comentarios a Ars Technica. "Esto podría usarse para romper el cifrado de disco en casos en los que un atacante tenga acceso temporal a la red (y sería aún más fácil en un escenario de robo)".
No es la primera falla grave en el código de arranque por red de EDK II. En enero de 2024, los investigadores revelaron PixieFail, un conjunto de nueve fallas en la misma parte de EDK II, también alcanzables durante el arranque PXE. Ars informó que los proyectos de fuzzing iniciados tras PixieFail para encontrar más errores en el código no detectaron este.
Deja una respuesta