Investigadores de Google y Anthropic detectaron falla de seguridad que afecta a la mayoría de centros de datos del mundo

La falla CVE-2026-97631 recibió una calificación de severidad de 9,5 sobre 10
INFOBAE.-Alex Matrosov, investigador de Anthropic, y Dan Holmes, de Google, descubrieron una falla en el código de arranque que utilizan la mayoría de proveedores de servidores y centros de datos del planeta, que dejó expuestos a millones de equipos frente a ataques capaces de ejecutar código malicioso antes de que cualquier sistema de defensa pueda activarse. La vulnerabilidad, identificada como CVE-2026-97631, recibió una calificación de severidad de 9,5 sobre 10 y afecta al TianoCore EDK II, el código abierto que las empresas de hardware emplean para construir el firmware UEFI que se ejecuta durante el inicio de los equipos.
El EDK2 es, según un representante del UEFI Forum, “la solución de referencia predominante” para implementar las especificaciones UEFI. Prácticamente todos los proveedores independientes de BIOS, entre ellos AMI, Insyde y Phoenix, utilizan de manera extensa este código base. También lo emplea Project Mu, la versión reforzada de EDK2 desarrollada por Microsoft, que incluye el componente vulnerable.
El fallo permite eludir el arranque seguro de los equipos
El problema reside en un componente del protocolo ICMP y consiste en una corrupción de memoria que un atacante puede aprovechar para ejecutar código antes de que el sistema operativo y el firmware puedan aplicar mecanismos de defensa como el Secure Boot. Esta función establece una cadena de confianza para todo el código que se carga durante el arranque, incluido el que corresponde al Trusted Platform Module (TPM).
Los ataques que exploten esta falla no logran persistencia, es decir, el código malicioso corre una sola vez. Sin embargo, esa única ejecución puede bastar para abrir la puerta a otros programas maliciosos que sí se instalen de forma permanente y se activen en cada arranque posterior del equipo.
Un fallo de 16 años en el controlador de arranque por red
CVE-2026-97631 corresponde a un desbordamiento de búfer presente desde hace 16 años en el controlador PXE-Base Code (NetworkPkg/UefiPxeBcDxe), responsable de que servidores, equipos de almacenamiento y otros dispositivos puedan iniciarse con código descargado desde una red local. Durante ese proceso, conocido como entorno de pre-ejecución de arranque, el controlador mantiene un escucha de red para detectar mensajes de error ICMP.
El defecto radica en que el controlador no impone un límite de copia de memoria de 504 bytes, por lo que los datos adyacentes pueden sobrescribirse. Un atacante con acceso de bajo nivel a una red local, o un usuario malicioso dentro de esa red, puede enviar un mensaje de error que agregue código más allá de ese límite, lo que corrompe el módulo UEFI que corre en el procesador.
El aviso oficial del proyecto explica que el controlador PXE Base Code mantiene abierta una solicitud de recepción para mensajes de error ICMP y copia cada mensaje recibido en un campo fijo de 504 bytes dentro de su estructura de contexto privada.
Tanto en el manejador de IPv4 como en el de IPv6, el control de límites está mal implementado: si el mensaje supera los 504 bytes, el sistema igual copia los bytes excedentes, y el puntero de destino avanza según la longitud acumulada en lugar de la longitud de cada fragmento, lo cual permite que un mensaje de tamaño excesivo escriba datos controlados por el atacante fuera del campo previsto. Nada en el camino de recepción anterior restringe la longitud del mensaje.
Un ataque que puede ejecutarse con un simple envío unicast
El error malicioso puede entregarse mediante un envío unicast simple desde cualquier distancia de red hacia la dirección IP del dispositivo objetivo, siempre que se transmita durante la secuencia de arranque PXE. Un atacante puede provocar una denegación de servicio con solo hacer que la secuencia de arranque se bloquee. Si además conoce la versión específica del firmware del objetivo, puede introducir lo que el aviso describe como un “evento falsificado” que ejecuta código malicioso directamente sobre el procesador dentro de su entorno de firmware UEFI.

Ese código corre en el anillo 0 (ring 0), el nivel de ejecución más privilegiado de un procesador. Según explicó HD Moore, creador de Metasploit y director de investigación en la firma de seguridad Dragos, esta falla en el analizador ICMP de la pila de red de EDK2 resulta relevante por su efecto sobre la cadena de confianza y el ecosistema en general.
Moore señaló que un atacante interesado en comprometer un terminal o servidor cercano podría usar este error para secuestrar el flujo del programa en un punto donde el proceso de arranque todavía tiene acceso a componentes sensibles, como el TPM del dispositivo, lo que podría emplearse para romper el cifrado de disco en escenarios donde el atacante cuenta con acceso de red de corto plazo, una situación aún más sencilla en un caso de robo físico del equipo.
Los exploits que aprovechan esta vulnerabilidad logran además eludir los procesos de verificación diseñados para demostrar de forma criptográfica a servidores remotos que el hardware es seguro, lo que representa una vía concreta para escalar privilegios limitados.
La divulgación se adelantó al plazo previsto
Matrosov y Holmes habían acordado mantener la falla en reserva hasta una divulgación coordinada prevista para enero. Sin embargo, AMI publicó el mes pasado una solicitud de incorporación de código que detallaba la vulnerabilidad e incluía una corrección. Una vez que esa publicación llegó a conocimiento de los descubridores originales, los miembros del proyecto TianoCore emitieron un aviso público la semana pasada.
Con el código de parche ya disponible públicamente, resultará sencillo para atacantes con conocimientos avanzados comprender cómo se activa la vulnerabilidad y construir exploits funcionales. La urgencia se agrava porque corregir fallas de código UEFI en millones de dispositivos finales, vendidos y utilizados por miles de fabricantes de hardware y proveedores de nube, es un proceso lento y complejo. Esta revelación se produjo seis días después de otra divulgación igualmente apresurada, en ese caso sobre una vulnerabilidad crítica de ejecución de código en el lenguaje de programación PHP.






