La empresa de seguridad de firmware Binarly ha identificado seis nuevas vulnerabilidades en U-Boot, el pequeño programa que inicia hardware tan diverso como routers domésticos, cámaras inteligentes y los chips de gestión en servidores de centros de datos. Cuatro de los fallos pueden bloquear un dispositivo. Los otros dos podrían permitir que un atacante, al introducir una imagen maliciosa en el gestor de arranque, ejecute su propio código antes de que el dispositivo confirme que el software es genuino.
El gestor de arranque se ejecuta antes que el sistema operativo, por lo que un fallo aquí puede socavar todo lo que se carga después. Las seis vulnerabilidades se activan mientras U-Boot aún está leyendo una imagen no confiable, antes de verificar la firma.
Lo que Binarly encontró
U-Boot puede empaquetar un kernel, árbol de dispositivos, ramdisk y otros componentes de arranque en un solo paquete FIT (Flattened Image Tree), y verifica la firma digital de ese paquete antes de ceder el control. Binarly buscó puntos débiles en esa verificación y encontró seis. La mayoría del código vulnerable ha estado en U-Boot desde la versión v2013.07, según Binarly, a lo largo de más de 50 versiones estables, y también reside en muchos firmwares de proveedores construidos sobre U-Boot.
Los fallos se rastrean como avisos de Binarly BRLY-2026-037 a BRLY-2026-042. Aún no se han asignado identificadores CVE. Se dividen en dos grupos: dos que podrían ejecutar código y cuatro que solo provocan un bloqueo.
Los dos primeros son BRLY-2026-037 y BRLY-2026-038, y ambos se originan en un valor no verificado. U-Boot llama a fdt_get_name, una búsqueda en la biblioteca de análisis de árbol de dispositivos que utiliza prestada, y en una imagen malformada, esa búsqueda devuelve un puntero nulo y una longitud negativa. U-Boot usa ambos sin verificarlos. Un fallo sigue el puntero nulo hacia una copia de memoria que, en dispositivos donde la dirección cero está mapeada, se convierte en un desbordamiento de búfer en la pila. El otro alimenta la longitud negativa en operaciones aritméticas de punteros que retroceden hasta sobrescribir una dirección de retorno guardada. Con el diseño de memoria adecuado, cualquiera de estos puede entregar el control al código proporcionado por el atacante.
Los otros cuatro solo bloquean el gestor de arranque. BRLY-2026-039 y BRLY-2026-041 leen más allá del final de la imagen al confiar en un tamaño o desplazamiento controlado por el atacante. BRLY-2026-040 desreferencia un puntero nulo que un formato de imagen antiguo devuelve sin verificar. BRLY-2026-042 agota la pila, provocado por una imagen profundamente anidada que obliga a un paso de validación temprano a llamarse a sí mismo hasta quedarse sin recursos.
Binarly publicó una imagen de prueba de concepto y pasos de reproducción para cada fallo, y los demostró contra compilaciones estándar de U-Boot. No se ha reportado explotación en ataques reales. De los seis, los dos fallos de corrupción de memoria son los prioritarios: un bloqueo puede desconectar un dispositivo, pero la ejecución de código en el arranque podría subvertir toda su cadena de confianza.
Gravedad de la situación
En el peor caso, recuperar un dispositivo que no arranca requiere acceso físico y volver a flashear su chip de memoria con una imagen limpia. La ejecución de código es peor. El código que se ejecuta tan temprano se sitúa por debajo del sistema operativo, donde las herramientas de seguridad habituales pueden no detectarlo. El inconveniente para un atacante es la entrega: estos fallos solo se activan cuando una imagen maliciosa llega a la ruta de arranque, lo que normalmente requiere acceso físico o un punto de apoyo privilegiado. Ese punto de apoyo no siempre es local.
En trabajos anteriores sobre los controladores de gestión de servidores Supermicro, el mismo investigador de Binarly demostró que un atacante con acceso remoto a la interfaz de gestión podría abusar del propio proceso de actualización del dispositivo para flashear una imagen maliciosa, sin tocar el hardware.
Qué hacer
Aún no hay una versión estable con la corrección, por lo que los proveedores y mantenedores de productos basados en U-Boot no deben esperar: apliquen las correcciones de upstream ahora, siguiendo los enlaces de confirmación en cada aviso de Binarly, y realicen un seguimiento por ID de aviso, ya que no existen CVEs. U-Boot fusionó los seis parches en junio, pero la versión de julio (v2026.07) ya se había congelado en abril, por lo que se lanzó sin ellos; la próxima versión, v2026.10, no está prevista hasta octubre.
El resto ejecuta un dispositivo que alguien más construyó sobre U-Boot. Para ellos, la corrección debe llegar como una actualización de firmware del proveedor del producto. Eso es lo que hay que vigilar. Esta misma verificación ya ha fallado antes. La misma lógica de firma fue afectada meses antes por CVE-2026-33243, que U-Boot parcheó en abril; el gestor de arranque relacionado barebox, que utiliza las mismas herramientas de imagen, también fue afectado.
En ese fallo, una propiedad destinada solo a enumerar lo que cubre la firma no estaba firmada, por lo que una imagen manipulada podía intercambiar partes que nunca fueron verificadas. La función auxiliar detrás de los dos peores fallos aquí, fdt_get_name, proviene de libfdt, la biblioteca de árbol de dispositivos planos que U-Boot comparte con el kernel de Linux, barebox y otros. El mismo error de retorno no verificado puede aparecer en cualquier lugar donde se use ese código.
LogoFAIL, que THN cubrió en 2023, fue un conjunto de fallos de análisis de imágenes en firmware de PC que permitió la ejecución de código atacante durante el arranque, antes de que Secure Boot pudiera verificar nada, en casi todas las principales marcas de PC. La firma recibe toda la atención; los fallos siguen apareciendo en la infraestructura que se ejecuta antes que ella.
Y como mostró BootHole en 2020, cuando un fallo en el gestor de arranque rompió Secure Boot en todo el ecosistema, escribir el parche es la parte fácil. La parte lenta es implementarlo en los millones de dispositivos que ejecutan una copia de U-Boot de otro proveedor.
