Una vulnerabilidad con una gravedad de 9,5 sobre 10 permite ejecutar código malicioso durante las primeras etapas del arranque de un equipo. El problema afecta a EDK II, una base de código utilizada por fabricantes de hardware y proveedores de servicios en la nube, y obliga a revisar la seguridad de miles de infraestructuras tecnológicas.
Una vulnerabilidad de seguridad descubierta en uno de los componentes fundamentales del arranque de los servidores encendió las alarmas entre especialistas en ciberseguridad. El fallo afecta a TianoCore EDK II, una plataforma de código abierto utilizada por fabricantes de hardware y proveedores de servicios en la nube para desarrollar el firmware UEFI, responsable de iniciar los equipos antes de que se cargue el sistema operativo.
Identificada como CVE-2026-97631, la falla tiene una calificación de gravedad de 9,5 sobre 10 y permite que un atacante ejecute código malicioso en una etapa temprana del proceso de arranque. Su importancia radica en que puede comprometer la cadena de confianza del equipo antes de que entren en funcionamiento mecanismos de protección como Secure Boot y el Trusted Platform Module (TPM).
EDK II es una pieza ampliamente utilizada en la industria. El código de referencia es empleado por proveedores de firmware como AMI, Insyde y Phoenix, mientras que también forma parte de Project Mu, la versión reforzada de EDK2 desarrollada por Microsoft. El UEFI Forum llegó a describirlo como la implementación de referencia más destacada de sus especificaciones.
Un error de memoria que permite ejecutar código antes del sistema operativo
El origen del problema es una vulnerabilidad de corrupción de memoria en un componente ICMP del controlador PXE-Base Code, identificado como NetworkPkg/UefiPxeBcDxe. Se trata de un código que permite que servidores, equipos de almacenamiento y otros dispositivos arranquen utilizando instrucciones descargadas desde una red local.
Durante ese procedimiento, conocido como arranque PXE o entorno de preejecución, el controlador recibe mensajes de error ICMP. El problema aparece porque no controla correctamente el límite de memoria de 504 bytes destinado a almacenar esos mensajes.
Cuando recibe un mensaje más largo, el código puede copiar información más allá del espacio reservado y sobrescribir datos adyacentes. La falla está presente tanto en los controladores para IPv4 como para IPv6.
Un atacante con acceso de bajo nivel a la red puede enviar un mensaje especialmente diseñado a la dirección IP del dispositivo durante la secuencia de arranque. Si conoce la versión del firmware utilizado, puede intentar manipular el flujo de ejecución y conseguir que el procesador ejecute código malicioso en el entorno UEFI, con privilegios de nivel 0 (ring 0), el nivel más elevado de acceso del procesador.
Aunque la carga maliciosa inicial no tiene persistencia y se ejecuta una sola vez, puede abrir el camino para instalar otros componentes que sí se activen durante futuras etapas tempranas del arranque.
El investigador de seguridad HD Moore, creador de Metasploit y director de investigación de la firma Dragos, explicó que un atacante podría aprovechar el fallo para tomar el control del flujo de ejecución cuando el proceso de arranque todavía tiene acceso a componentes sensibles, como el TPM. Según señaló, esto podría utilizarse para romper el cifrado de discos en determinadas circunstancias, por ejemplo, cuando el atacante tiene acceso temporal a la red o consigue acceso físico al equipo.
Anthropic y Google descubrieron la vulnerabilidad
La falla fue descubierta por Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google. Ambos habían coordinado una divulgación controlada cuya publicación estaba prevista originalmente para enero.
Sin embargo, el proceso se alteró cuando AMI, fabricante de placas madre y otros componentes de hardware, publicó el mes pasado una solicitud de cambios de código (pull request) que describía la vulnerabilidad e incluía una corrección.
Después de que los investigadores que descubrieron el problema tomaran conocimiento de esa publicación, integrantes del proyecto TianoCore difundieron un aviso de seguridad público.
La disponibilidad del código de corrección también expuso detalles técnicos sobre el funcionamiento de la falla. Esto aumenta la preocupación de los especialistas, ya que investigadores y atacantes avanzados pueden estudiar cómo se activa y desarrollar herramientas para explotarla.
El problema se agrava por la dificultad de actualizar el firmware UEFI en millones de dispositivos distribuidos entre miles de fabricantes y proveedores de infraestructura tecnológica. A diferencia de una actualización de software convencional, corregir estas vulnerabilidades requiere que los fabricantes desarrollen y distribuyan nuevas versiones del BIOS o UEFI para los equipos afectados.
Qué empresas y equipos pueden estar afectados
La vulnerabilidad no afecta indiscriminadamente a todos los usuarios. El riesgo se concentra en organizaciones cuyos servidores y dispositivos arrancan desde redes locales —o potencialmente desde recursos conectados a Internet—, utilizan firmware basado en EDK II y tienen habilitada la funcionalidad PXE, que viene activada de manera predeterminada.
Los equipos que arrancan exclusivamente desde unidades de disco, como las computadoras domésticas y de pequeñas oficinas, no están alcanzados por el escenario descrito.
También existen limitaciones para explotar el fallo. El atacante necesita cierto nivel de acceso a la red local y debe conocer características específicas del firmware de destino. Jesse Michael, investigador principal de la firma de seguridad de firmware Eclypsium, explicó que no es posible utilizar un único exploit contra cualquier dispositivo: el ataque debe adaptarse al modelo, la versión y la configuración de cada equipo.
Michael también señaló que, a diferencia de vulnerabilidades anteriores como BootHole, BlackLotus y Baton Drop, esta falla puede corregirse mediante una modificación de código y una actualización del BIOS o UEFI, sin necesidad de realizar cambios adicionales en la gestión de claves de Secure Boot.
Intel informó que no conoce productos comerciales actualmente bajo soporte de seguridad que estén afectados. La compañía aclaró que no incluye la funcionalidad vulnerable de EDK II en su código de referencia, aunque esta podría haber sido incorporada por fabricantes de placas o sistemas. Por eso, recomendó consultar con el fabricante del equipo.
Arm, por su parte, afirmó que CVE-2026-97631 no se aplica directamente a su cartera de productos. Sin embargo, el código de firmware que la compañía pone a disposición también utiliza componentes de EDK II.
El informe señala que AMD, Phoenix Technologies, AMI, Microsoft y Amazon no habían respondido a las consultas realizadas al momento de su publicación. Tampoco lo habían hecho representantes del proyecto TianoCore. Por esa razón, todavía no es posible determinar con precisión qué cantidad de dispositivos de cada fabricante está comprometida.
Una vulnerabilidad que puede permanecer durante años
CVE-2026-97631 se suma a una lista de problemas de seguridad relacionados con UEFI, entre ellos LogoFail, PixieFail, PKFail, BootHole y BlackLotus. Todos reflejan los riesgos de comprometer componentes que intervienen antes de que el sistema operativo y sus mecanismos de protección comiencen a funcionar.
HD Moore advirtió que, por la amplitud del ecosistema afectado, es probable que se convierta en una vulnerabilidad de larga duración, que permanezca en equipos que lleguen al final de su ciclo de soporte.
Para las organizaciones, la recomendación es consultar con los fabricantes del firmware y verificar si sus equipos utilizan EDK II y la funcionalidad PXE. También se aconseja desactivar temporalmente el arranque por red cuando sea posible, mantener habilitados TPM y Secure Boot —aunque estas protecciones no bloquean específicamente esta amenaza— y monitorear los registros del sistema en busca de intentos de explotación.
El episodio vuelve a poner en evidencia un desafío central para la industria tecnológica: la seguridad de los centros de datos y los servidores no depende solamente de los sistemas operativos, las aplicaciones o los modelos de inteligencia artificial, sino también de componentes de firmware que pueden llevar más de una década funcionando dentro de la infraestructura crítica de las empresas.
