UEFI: fallo crítico 9.5/10 amenaza servidores globales

Qué es la CVE-2026-97631 y por qué pesa 9,5 sobre 10

El fallo vive en TianoCore EDK II, la base de código abierta que fabricantes de hardware y proveedores de nube usan para construir el firmware UEFI que corre durante la secuencia de arranque. Un representante del UEFI Forum lo describió como la solución e implementación preeminente de las especificaciones UEFI, y prácticamente todos los proveedores de UEFI —también llamados IBV, o independent BIOS vendors—, incluidos AMI, Insyde y Phoenix, usan ese código de referencia de forma extensiva. Project Mu, el fork endurecido de EDK2 que mantiene Microsoft, también usaba el componente vulnerable.

Técnicamente es una corrupción de memoria en un componente ICMP. Quien la explota ejecuta código malicioso antes de que el sistema operativo y el propio firmware puedan aplicar defensas como Secure Boot, que establece la cadena de confianza de todo el código cargado durante el arranque, incluido el Trusted Platform Module (TPM).

Los payloads finales que entrega la CVE-2026-97631 no tienen persistencia: se ejecutan una sola vez. Pero esa ventana alcanza para instalar otros payloads que sí corren en cada arranque, muy por debajo de donde mira la mayoría de las herramientas de seguridad.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La divulgación se rompió antes de tiempo

Alex Matrosov, de Anthropic, y Dan Holmes, de Google, descubrieron la vulnerabilidad y habían acordado mantenerla bajo reserva hasta una divulgación coordinada prevista para enero. El plan se cayó cuando AMI, fabricante de placas madre y otro hardware, publicó un pull request que detallaba el fallo e incluía un parche de código. Cuando los descubridores lo detectaron, los miembros del proyecto TianoCore publicaron un aviso público.

Con el código del parche a la vista, para un atacante avanzado es trivial entender cómo se dispara el fallo y armar un exploit funcional. La ventana entre que existe el parche y existe el exploit se mide en horas, no en semanas.

El episodio llega seis días después de otra divulgación fallida: una vulnerabilidad crítica de ejecución de código en el lenguaje PHP. Dos casos en una semana apuntan a un problema de proceso, no a una coincidencia.

Por qué parchear firmware UEFI es tan lento

El firmware no se actualiza como una aplicación. Cada placa, cada modelo y cada generación de servidor tiene su propio binario, y el parche tiene que recorrer una cadena completa: el proyecto upstream publica la corrección, el IBV la integra en su producto, el fabricante del equipo la valida y el operador final la despliega. Cada salto suma meses.

En servidores, además, actualizar firmware implica ventanas de mantenimiento, reinicios y riesgo real de dejar un equipo inutilizable si algo sale mal. Por eso muchas organizaciones posponen la actualización indefinidamente.

Y hay un detalle que complica todo: Secure Boot no protege contra este fallo. El código malicioso corre antes de que Secure Boot pueda evaluar nada. La defensa que la industria vendió durante una década como barrera de arranque no cubre un ataque que ocurre una capa más abajo.

El firmware es el eslabón que nadie parchea

Este caso no es aislado. El patrón se repite con una consistencia incómoda.

En julio de 2026, ESET reportó el hallazgo de 11 shims UEFI antiguos firmados por Microsoft, en versiones 0.9 y anteriores, que permitían eludir Secure Boot en la mayoría de los sistemas basados en UEFI. Los binarios fueron revocados por Microsoft. El investigador de ESET Martin Smolár lo resumió así: lo peligroso no era una vulnerabilidad nueva, sino que no hacía falta ninguna para saltarse Secure Boot.

Antes, ESET había divulgado CVE-2024-7344, un bypass de Secure Boot en una aplicación UEFI firmada con el certificado de terceros de Microsoft, que fue revocada en la actualización del 14 de enero de 2025. Y antes de eso, Eclypsium había encontrado CVE-2022-34302, con exactamente la misma causa raíz: un cargador propio e inseguro en lugar de las funciones estándar de UEFI.

El caso más reciente lo documentaron BleepingComputer y The Hacker News: BlackX, un bootkit UEFI usado en una campaña de espionaje a inicios de 2026 contra agencias diplomáticas de Asia Central, explotó la vulnerabilidad Baton Drop (CVE-2022-21894) —la misma que usó el conocido BlackLotus—. El detalle que debería preocupar a cualquier responsable de infraestructura: todas las víctimas corrían versiones de Windows completamente parcheadas. El parche existía, pero la revocación del certificado requería una acción manual que nadie ejecutó. El certificado Windows Production PCA 2011 expiró el 19 de octubre de 2026, y eso tampoco impide que los binarios vulnerables se sigan cargando si no están en la lista de bloqueo.

Ya en 2023, Ars Technica documentó que Microsoft tardó casi un año en completar el parcheo de CVE-2023-24932, y que la corrección llegó desactivada por defecto para no romper equipos.

¿Qué significa esto para tu startup?

Si tu producto corre íntegramente en nube gestionada, el riesgo técnico directo es del proveedor. Pero tu obligación no desaparece: cuando un cliente enterprise te envíe un cuestionario de seguridad, va a preguntar por el ciclo de vida del firmware de la infraestructura donde viven sus datos.

Si tienes servidores on-premise, colocation, hardware propio o vendes dispositivos conectados, el problema es tuyo y de nadie más. Y si tu startup vende a sector público, banca o defensa, este tipo de vulnerabilidad entra directo en tus requisitos de cumplimiento.

La lección transversal es la del caso BlackX: el parche instalado no equivale al parche activo. La brecha entre ambos es exactamente donde operan los atacantes.

Qué hacer esta semana

Levanta el inventario de firmware. Qué modelos de servidor y equipo tienes, qué IBV los provee (AMI, Insyde, Phoenix u otro) y qué versión de firmware corre en cada uno. Sin ese mapa no puedes priorizar nada.
Pregunta por escrito a tu proveedor de nube o colocation. Pide su plan y su fecha comprometida para CVE-2026-97631. Una respuesta vaga es información útil: significa que tú tienes que asumir el riesgo.
Verifica las revocaciones de Secure Boot, no solo las actualizaciones. En el caso de CVE-2024-7344, ESET publicó comandos de PowerShell y de dbxtool para comprobar si el binario vulnerable está en la lista de prohibidos (dbx). El mismo tipo de verificación aplica aquí: instalar no es revocar.
Reduce la superficie de ataque. Restringe el acceso a la partición del sistema EFI, segmenta la red de gestión y activa atestación remota con TPM para detectar modificaciones del arranque. Son controles que ya existen en la mayoría de los stacks y que casi nadie enciende.
Si vendes hardware, mete el firmware en el contrato. Define una política de respuesta a vulnerabilidades con plazos, y no solo para esta CVE.

Conclusión

La conclusión no es que Secure Boot sea inútil, sino que la cadena de confianza tiene un eslabón que se actualiza a un ritmo distinto al del resto del stack. Ningún founder controla a TianoCore, a AMI ni a los ciclos de validación de los fabricantes de servidores.

Lo que sí puedes controlar es saber qué corre en tu infraestructura y exigir fechas concretas a quien te la provee. La pregunta que vale la pena hacerse no es si tu sistema es vulnerable a CVE-2026-97631, sino cuánto tardarías en enterarte de que lo es.