La infraestructura digital global enfrenta una nueva amenaza tras descubrirse una vulnerabilidad crítica en el proceso de arranque de servidores y centros de datos. Identificada como CVE-2026-97631, con una puntuación de gravedad de 9,5 sobre 10, la falla afecta a TianoCore EDK II, una base de código abierto ampliamente utilizada para desarrollar firmware UEFI, según reportes de Ars Technica.
Descubierta por Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, la vulnerabilidad podría permitir que un atacante ejecute código malicioso en una fase especialmente sensible del arranque, antes de que el sistema operativo cargue y de que mecanismos como Secure Boot verifiquen sus componentes. Esta ejecución puede alcanzar el nivel de privilegios Ring 0 del procesador, comprometiendo la seguridad del entorno UEFI.
En esta entrega de Alerta Digital, analizamos cómo un error de desbordamiento de búfer presente desde hace aproximadamente 16 años amenaza la cadena de confianza de los servidores, las consecuencias de su divulgación prematura y los desafíos que enfrentan los proveedores para distribuir actualizaciones de seguridad.
Un desbordamiento de búfer en el arranque de red (PXE)
La vulnerabilidad se encuentra en el controlador NetworkPkg/UefiPxeBcDxe, utilizado para iniciar equipos mediante software descargado desde una red, a través del entorno de ejecución previo al arranque, conocido como PXE (Preboot Execution Environment). Durante este proceso, el controlador permanece a la espera de determinados mensajes de error ICMP.
El problema surge por un manejo incorrecto de los límites de memoria al copiar información dentro de la estructura Mode.IcmpError, que dispone de un espacio fijo de 504 bytes:
- Ausencia de límites adecuados: el controlador puede procesar mensajes ICMP que superan la capacidad disponible, debido a errores en la comprobación de los tamaños y en el cálculo de los desplazamientos de memoria.
- Corrupción de memoria: un mensaje especialmente manipulado puede sobrescribir información situada fuera del búfer asignado. Esto podría provocar fallos durante el arranque o alterar estructuras internas del firmware.
- Ejecución de código en Ring 0: bajo determinadas condiciones, un atacante que conozca la versión y configuración del firmware podría manipular el flujo de ejecución durante la fase DXE de UEFI. Esto permitiría ejecutar código antes de que entren en funcionamiento las protecciones habituales del sistema operativo.
Del embargo confidencial a la alerta pública
La divulgación coordinada de CVE-2026-97631 estaba prevista originalmente para enero. Sin embargo, una solicitud pública de modificación de código (pull request) relacionada con una corrección desarrollada por un proveedor de firmware expuso información sobre el problema antes de lo previsto. Ante esta situación, TianoCore publicó un aviso de seguridad el 22 de octubre.
La exposición anticipada supone un desafío para una cadena de suministro tecnológica particularmente amplia:
- Proveedores independientes de firmware: empresas como AMI, Insyde y Phoenix utilizan componentes derivados de EDK II. Sin embargo, la presencia de este código no significa que todos sus productos sean necesariamente vulnerables.
- Proyectos derivados: iniciativas como Project Mu, de Microsoft, también incorporan componentes de EDK II, por lo que requieren revisiones específicas para determinar su exposición.
- Disponibilidad de información técnica: la publicación del código correctivo facilita el análisis del fallo, tanto para los equipos de seguridad como para potenciales atacantes. No obstante, desarrollar una explotación funcional requiere conocer características concretas del firmware utilizado.
La corrección fue incorporada a la rama principal del código de EDK II el 15 de octubre. Sin embargo, al 29 de octubre todavía no figuraba en una versión estable publicada. Por ello, los fabricantes y administradores deben comprobar la disponibilidad de actualizaciones específicas para sus equipos.
Alcance real y limitaciones prácticas
A pesar de su elevada gravedad, CVE-2026-97631 no permite atacar indiscriminadamente cualquier servidor conectado a Internet. Su explotación requiere que el equipo vulnerable esté realizando un arranque mediante PXE y que el atacante pueda enviarle mensajes ICMP durante esa ventana de tiempo.
El riesgo afecta principalmente a servidores, entornos de virtualización e infraestructuras que utilizan el arranque por red. Los equipos personales que inician exclusivamente desde unidades locales no están expuestos a este mecanismo de ataque, aunque conviene comprobar que PXE no permanezca habilitado como alternativa de arranque.
Asimismo, el atacante necesita conectividad hacia el sistema objetivo, pero no necesariamente acceso físico ni presencia dentro de la misma red local. Las posibilidades reales de explotación dependerán de las restricciones de red, los filtros de tráfico y la configuración de cada infraestructura.
Para conseguir una ejecución de código fiable, también es necesario conocer detalles específicos de la versión del firmware, debido a las diferencias en las direcciones de memoria entre fabricantes y configuraciones.
Mientras llegan las actualizaciones, los especialistas recomiendan deshabilitar el arranque por red cuando no sea necesario, restringir el acceso a las redes de aprovisionamiento y verificar con los fabricantes si los sistemas utilizados están afectados. Estas medidas resultan especialmente importantes para infraestructuras antiguas que ya no reciben mantenimiento.
La postura Web3: verificación de arranque e identidad inmutable de hardware
La aparición de vulnerabilidades como LogoFail, PixieFail, PKFail y ahora CVE-2026-97631 demuestra que la seguridad del firmware continúa siendo un desafío para la infraestructura digital. La distribución de parches puede requerir meses de coordinación entre desarrolladores, fabricantes y administradores, especialmente en centros de datos con miles de servidores.
En este escenario, las infraestructuras descentralizadas y las redes DePIN podrían incorporar mecanismos adicionales de verificación y auditoría:
- Atestación remota con registros on-chain: utilizar pruebas criptográficas para verificar determinadas características del entorno de ejecución y registrar sus resultados en una blockchain. Esto permitiría disponer de un historial verificable de las comprobaciones realizadas antes de autorizar operaciones sensibles.
- Gobernanza transparente de parches: mantener registros verificables sobre las versiones de firmware utilizadas y las actualizaciones aplicadas por los nodos de una red. Esta información podría facilitar auditorías y ayudar a identificar equipos que requieren mantenimiento.
Sin embargo, la tecnología blockchain no elimina las vulnerabilidades del firmware ni garantiza por sí sola la integridad del hardware. La eficacia de estos mecanismos depende de que las mediciones iniciales sean confiables y de que los sistemas de atestación no hayan sido comprometidos.
Por tanto, la respuesta a CVE-2026-97631 deberá combinar actualizaciones de firmware, aislamiento de redes, controles de arranque y mecanismos de verificación. La prioridad consiste en impedir que una vulnerabilidad presente antes de cargar el sistema operativo comprometa la confianza sobre la que funcionan las infraestructuras digitales.
