Por Canuto  

Una falla de ejecución de código en EDK2 puede afectar a servidores que arrancan mediante PXE y permitir que un atacante manipule el firmware antes de que carguen el sistema operativo y algunas defensas. La vulnerabilidad tiene una gravedad de 9,5 sobre 10, pero su explotación exige condiciones específicas y los operadores deben confirmar con sus fabricantes si sus equipos están expuestos.
***

  • CVE-2026-97631 es un desbordamiento de búfer de 16 años en el controlador PXE de EDK2, usado como base por numerosos fabricantes de firmware.
  • Un mensaje ICMP sobredimensionado durante el arranque por red puede corromper memoria y abrir la puerta a ejecutar código en el firmware UEFI.
  • El riesgo se concentra en equipos con EDK2 y PXE habilitado; los operadores deben consultar a sus proveedores y valorar desactivar temporalmente el arranque por red.

 

Una falla de ejecución de código en EDK2, una base de código abierta utilizada para construir firmware UEFI, encendió las alertas entre fabricantes y operadores de centros de datos. Registrada como CVE-2026-97631 y calificada con una gravedad de 9,5 sobre 10, la vulnerabilidad puede explotarse durante el arranque por red para intervenir antes de que el sistema operativo y sus protecciones habituales entren en funcionamiento.

El riesgo no alcanza automáticamente a todos los servidores ni a los usuarios que inician sus equipos desde discos locales. Depende de que el firmware esté basado en EDK2 y de que el dispositivo use PXE, una tecnología que permite cargar código de arranque desde una red; por eso, las organizaciones deben verificar sus configuraciones con los fabricantes antes de concluir si están expuestas.

Un fallo en una etapa temprana del arranque

EDK2, mantenido por el proyecto TianoCore, sirve como referencia para construir implementaciones de UEFI, el firmware que inicializa el equipo antes de que arranque el sistema operativo. Según la información publicada por Ars Technica, numerosos proveedores de firmware, entre ellos AMI, Insyde y Phoenix, aprovechan código de esa base; también lo hacía Project Mu, la bifurcación de EDK2 endurecida por Microsoft.

La vulnerabilidad se encuentra en el controlador PXE-Base Code, identificado como NetworkPkg/UefiPxeBcDxe, que participa en el arranque desde una red local. Durante ese proceso, el controlador mantiene abierta una recepción de mensajes de error ICMP, un protocolo empleado por los dispositivos de red para comunicar problemas; el error aparece cuando procesa mensajes cuyo contenido excede el espacio de memoria previsto.

El campo Mode.IcmpError de la estructura privada del controlador tiene una capacidad fija de 504 bytes, pero los manejadores para IPv4 e IPv6 no controlan correctamente el límite de copia. Si reciben un mensaje más largo, copian bytes adicionales fuera del campo y, además, avanzan el puntero de destino usando la longitud acumulada, en vez de la longitud correspondiente a cada fragmento. El resultado es una corrupción de memoria con datos que puede controlar un atacante.

El problema lleva 16 años en el código y puede presentarse durante el arranque PXE, antes de que el sistema operativo comience a ejecutarse. Un mensaje malicioso puede provocar que el proceso de inicio se cuelgue, mientras que una explotación dirigida podría alterar el flujo del programa y ejecutar código en el entorno UEFI de la CPU, con privilegios de anillo 0, el nivel más alto de ejecución descrito en la información técnica.

Las implicaciones para la cadena de confianza

El momento de la ejecución es una parte central del riesgo: el código corre antes de que se activen defensas del sistema operativo y de que puedan intervenir controles vinculados con Secure Boot. Esta función busca establecer una cadena de confianza para el código que se carga durante el inicio, incluido el relacionado con el Trusted Platform Module (TPM), pero la vulnerabilidad permite actuar en una etapa previa a esas protecciones.

HD Moore, creador de Metasploit y director de investigación de Dragos, señaló a Ars Technica que un atacante con acceso a un punto cercano al servidor podría secuestrar el flujo del programa cuando el proceso de arranque aún interactúa con componentes sensibles, como el TPM. Moore advirtió que, en determinadas circunstancias, esto podría facilitar la ruptura del cifrado de disco, especialmente si el atacante dispone de acceso temporal a la red o logra robar el equipo.

La carga ejecutada directamente mediante CVE-2026-97631 no persiste después de esa ejecución, por lo que el ataque inicial no se conserva por sí mismo entre reinicios. Sin embargo, el acceso temprano al firmware puede dar al intruso la oportunidad de instalar otras cargas que sí se ejecuten en arranques posteriores, lo que convertiría una intrusión temporal en un compromiso de mayor duración.

Los investigadores Alex Matrosov, de Anthropic, y Dan Holmes, de Google, habían acordado mantener el hallazgo bajo reserva hasta una divulgación coordinada prevista para enero de 2027. La situación cambió cuando AMI publicó en septiembre de 2026 una solicitud de cambios con detalles de la falla y una corrección; luego de que los descubridores conocieran esa publicación, TianoCore difundió un aviso público la semana pasada. Con el parche disponible, especialistas pueden estudiar cómo activar el error y desarrollar exploits.

Explotación condicionada y respuesta pendiente

La posibilidad de ejecución remota no significa que cualquier equipo conectado a internet pueda atacarse de forma automática. El dispositivo debe estar arrancando mediante PXE cuando recibe el mensaje, y el atacante necesita alcanzar la red que permite enviarle tráfico; la información disponible no presenta la vulnerabilidad como un punto de entrada inicial a una organización ni aporta evidencia de explotación activa.

Jesse Michael, investigador principal de Eclypsium, explicó a Ars Technica que un atacante debe conocer o adivinar direcciones específicas del sistema objetivo. Como esas direcciones cambian según el modelo, la versión y la configuración del firmware, el exploit requiere adaptación para cada objetivo, en vez de funcionar como una herramienta única contra una amplia variedad de dispositivos.

Michael también indicó que, a diferencia de fallas anteriores relacionadas con el arranque seguro, esta vulnerabilidad podría corregirse con un cambio de código y una actualización de BIOS o UEFI. Según su explicación, la corrección no exige gestionar revocaciones ni actualizar las claves PK, KEK, db o dbx, ni modificar el sistema operativo y los medios de aprovisionamiento para responder a una omisión de Secure Boot en el gestor de arranque.

La exposición se limita principalmente a organizaciones con equipos que arrancan desde redes locales, o posiblemente desde recursos conectados a internet, y no afecta a quienes inician sus dispositivos únicamente desde unidades de disco. La información publicada recomienda preguntar al fabricante del firmware si el equipo utiliza el código vulnerable y considerar la desactivación temporal de las capacidades de arranque por red cuando sea viable; también aconseja mantener TPM y Secure Boot habilitados y vigilar los registros en busca de intentos de explotación.

Fabricantes, parches y el desafío de una falla ubicua

La respuesta de los proveedores seguía incompleta al momento de la publicación. Intel afirmó que no conocía productos comerciales actualmente bajo soporte de seguridad afectados y sostuvo que no incorpora la funcionalidad vulnerable de EDK2 en su código de referencia, aunque un fabricante de placas o de sistemas podría integrarla; la compañía recomendó consultar al fabricante del equipo.

Ars Technica contrastó esa respuesta con documentos públicos que hacen referencia a EDK2: el código de referencia de Intel lo menciona y TianoCore describe los kits de desarrollo UEFI suministrados por la compañía como implementaciones validadas para revisiones específicas de esa base. Arm dijo que la vulnerabilidad no se aplica directamente a su portafolio, aunque su firmware disponible públicamente también aprovecha EDK2 y TianoCore ha documentado esa dependencia.

AMD, Phoenix Technologies, AMI, Microsoft y Amazon no habían respondido a las consultas citadas cuando se publicó el artículo, y los representantes de TianoCore tampoco contestaron. Sin confirmaciones específicas, no era posible determinar qué modelos concretos estaban afectados ni qué medidas debían aplicar sus usuarios; por ello, la identificación del firmware instalado y la consulta al proveedor son pasos necesarios para cada organización.

La falla se suma a otros problemas de seguridad en UEFI, como LogoFail y PixieFail, además de BootHole, PKFail y BlackLotus, que muestran por qué los componentes anteriores al sistema operativo son objetivos atractivos. Ars Technica señaló que la ubicuidad del código y la dificultad de actualizar millones de equipos podrían dejar sistemas sin soporte expuestos durante años, aunque el ataque requiere condiciones específicas y no debe confundirse con una vulnerabilidad de entrada universal.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados