El firmware es el hueco de parches que nadie vigila, y el nuevo fallo de UEFI lo demuestra

Tu EDR es excelente, tu hipervisor está al día y tus imágenes de contenedores se reconstruyeron anoche. Entonces, ¿quién parchea el código que se ejecuta antes de que exista todo eso?

Esa es la incómoda pregunta que plantea CVE-2026-97631, un fallo crítico en TianoCore EDK II, la base de código de referencia de código abierto que utilizan la mayoría de los fabricantes de firmware UEFI. Según los resúmenes de la información de Ars Technica, está en un componente ICMP, en la ruta de arranque por red, y tiene una puntuación de 9,5 sobre 10. Permite a un atacante ejecutar código durante el arranque, antes de que protecciones como Secure Boot y el TPM puedan establecer una cadena de confianza.

Hay detalles que importan. Según se informa, las cargas maliciosas no persisten por sí solas, pero pueden instalar otro código que se ejecuta en cada arranque posterior. Además, el fallo se hizo público antes de una divulgación que estaba prevista para enero, según un resumen de FourWeekMBA sobre Ars. Y Jesse Michael, de Eclypsium, dijo a Ars que la solución pasa por desplegar una actualización de BIOS/UEFI.

«La mayoría de los servidores del planeta» es un titular, no una medición

Primero, algo de mesura. El titular dice que el fallo amenaza a la mayoría de los servidores del planeta. Como señala Tech Insider, la cobertura indica que el código de referencia lo usan la mayoría de los fabricantes de servidores del mundo, pero no da ninguna cifra de equipos afectados ni ningún porcentaje. Compartir código no es lo mismo que compartir exposición. Es probable que las compilaciones y configuraciones de cada fabricante difieran, y que el que un equipo concreto sea accesible por esa ruta de arranque por red dependa de cómo esté configurado.

Creemos que este matiz juega en ambas direcciones. Significa que no conviene reiniciar toda la flota esta noche presa del pánico. Y significa también que no puedes conocer tu exposición a partir de un titular, y sospechamos que muchas organizaciones tampoco pueden responder a esa pregunta con sus propios registros. Esa es la verdadera historia.

El fallo es nuevo; la cadena rota es antigua

Fíjate en cómo viaja la corrección de un firmware. En la cobertura de Ars de 2024 sobre una oleada anterior de fallos de UEFI, la cadena quedaba clara: los fabricantes de firmware envían actualizaciones a sus clientes, y esos clientes ponen los parches a disposición de los suyos, que suelen ser los usuarios finales. Cada salto es una empresa distinta y, en nuestra opinión, nadie es responsable de todo el recorrido.

Compáralo con un fallo en una biblioteca. Cuando salió a la luz hace poco un fallo de Brotli, Google y Node.js publicaron correcciones el 21 de octubre y Microsoft siguió con una actualización de emergencia de.NET durante el fin de semana, según TechRadar. Incluso eso fue un lío: las copias incluidas en otros paquetes hacen que actualizar solo la biblioteca de Google no proteja todas las aplicaciones. Pero al menos la corrección circula por canales que la mayoría de los equipos ya sabe manejar, como las actualizaciones de paquetes y los redespliegues. El firmware no ofrece una rutina así. Hay que averiguar qué imagen de qué fabricante usas, esperar a que el OEM la reempaquete, programar una ventana de mantenimiento y flashear máquinas que nadie quiere reiniciar.

Luego está la capa en la que los defensores suelen detectar un problema. El código previo al arranque se ejecuta por debajo del sistema operativo, así que las herramientas en las que se apoyan la mayoría de los equipos pueden tener muy poca visibilidad sobre él. Además, el firmware ha tenido unos meses malos. En septiembre, Cybernews informó de una elusión de Secure Boot mediante la UEFI Shell que reconocieron AMI, Gigabyte, Insyde y Cisco, con probablemente muchos más fabricantes afectados. Dos incidentes en dos meses no hacen tendencia por sí solos, pero sí apuntan a un punto débil.

Trata el firmware como un producto con responsable

Nuestro veredicto es sencillo: si el firmware no tiene responsable en tu equipo, ya has decidido parchearlo tarde. La solución es sobre todo de proceso, no de herramientas.

• Inventáríalo. Conoce qué versión de firmware y qué compilación de qué fabricante hay en cada servidor. Sin eso, responder a «¿estamos afectados?» lleva días en vez de minutos.
• Nombra a un responsable. Alguien debería seguir los avisos de los fabricantes y tener autoridad para programar ventanas de mantenimiento, igual que un equipo se encarga de la cadencia de parches de su sistema operativo.
• Reduce la superficie accesible. Si no necesitas el arranque por red en una máquina, desactivarlo puede ser una mitigación barata. No podemos prometer que cubra todas las configuraciones, así que comprueba lo que dice tu fabricante.
• Ensaya el flasheo. Una actualización de BIOS que nunca se ha practicado en tu hardware es una apuesta cuando de verdad importa.

Los fabricantes también tienen deberes. Una base de código de referencia compartida por todo el sector debería venir con una forma compartida y predecible de hacer llegar las correcciones a los clientes. Hasta que exista, la carga recae en los administradores, lo cual no es justo, pero es la realidad.

De este CVE no se recordará la puntuación. La pregunta que hay que hacerse es cuánto tardaría tu organización en saber cuáles de sus máquinas están expuestas. Si la respuesta sincera es «tendríamos que averiguarlo», el firmware es tu hueco de parches, y nadie más va a cerrarlo.