Investigadores de la firma de seguridad de firmware Binarly han encontrado seis nuevas fallas en U-Boot, el pequeño programa que inicia hardware tan variado como enrutadores domésticos, cámaras inteligentes y chips de administración dentro de servidores de centros de datos.
Cuatro de los errores pueden bloquear un dispositivo. Los otros dos podrían permitir que un atacante que introduzca una imagen maliciosa delante del gestor de arranque ejecute su propio código, antes de que el dispositivo haya confirmado que el software es genuino.
Esa última parte es el punto. Un gestor de arranque se ejecuta antes que el sistema operativo, por lo que una falla aquí puede socavar todo lo que se carga después. Los seis errores se detectan mientras U-Boot todavía está leyendo una imagen que no es de confianza, antes de verificar la firma.
Lo que encontró Binarly
U-Boot puede agrupar un kernel, un árbol de dispositivos, un disco ram y otros componentes de arranque en un solo paquete, un FIT (árbol de imágenes planas), y verifica la firma digital de ese paquete antes de ceder el control.
Binarly buscó puntos débiles en ese cheque y encontró seis. La mayor parte del código vulnerable ha estado en U-Boot desde la versión 2013.07, afirma Binarly, en más de 50 versiones estables, y también reside en los firmwares de muchos proveedores creados sobre U-Boot.
Los errores 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 pueden ejecutar código y cuatro que sólo fallan.
Los dos son BRLY-2026-037 y BRLY-2026-038, y ambos rastrean hasta un valor no verificado. U-Boot llama a fdt_get_name, una búsqueda en la biblioteca de análisis del árbol de dispositivos que toma prestada, y en una imagen con formato incorrecto, esa búsqueda devuelve un puntero nulo y una longitud negativa. U-Boot usa ambos sin verificar ninguno.
Un error sigue al puntero nulo en una copia de memoria que, en dispositivos donde está asignada la dirección cero, se convierte en un desbordamiento del búfer de pila. El otro introduce la longitud negativa en la aritmética de punteros que retrocede hasta que sobrescribe una dirección de retorno guardada. En el diseño de memoria correcto, cualquiera de los dos puede controlar manualmente la codificación proporcionada por el atacante.
Los otros cuatro sólo bloquean el gestor de arranque. BRLY-2026-039 y BRLY-2026-041 leen más allá del final de la imagen confiando en un tamaño o desplazamiento que controla el atacante. BRLY-2026-040 elimina la referencia a un puntero nulo que un formato de imagen anterior devuelve sin marcar. BRLY-2026-042 agota la pila, activada por una imagen profundamente anidada que impulsa un paso de validación temprano para llamarse a sí mismo hasta que se agote.
Binarly publicó una imagen de prueba de concepto y pasos de reproducción para cada defecto y los demostró frente a compilaciones estándar de U-Boot. No se ha informado de explotación en ataques reales.
De los seis, los dos errores de corrupción de memoria son los que se deben priorizar: una falla puede dejar un dispositivo fuera de línea, pero la ejecución del código en el arranque podría subvertir toda su cadena de confianza.
que mal se pone
En el peor de los casos, recuperar un dispositivo que no arranca significa acceder físicamente y actualizar su chip de memoria con una imagen limpia. La ejecución del código es peor. El código que se ejecuta tan temprano se encuentra debajo del sistema operativo, donde las herramientas de seguridad comunes pueden no verlo.
El problema para un atacante es la entrega: estos errores solo aparecen una vez que una imagen maliciosa llega a la ruta de inicio, que generalmente requiere acceso físico o un punto de apoyo privilegiado. Ese punto de apoyo no siempre es local.
En un trabajo anterior sobre los controladores de administración del servidor de Supermicro, el mismo investigador de Binarly demostró que un atacante con acceso remoto a la interfaz de administración podría abusar del propio proceso de actualización del dispositivo para mostrar una imagen maliciosa, sin tocar el hardware.
que hacer
Aún no existe una versión estable con la solución, por lo que los proveedores y mantenedores de productos basados en U-Boot no deberían esperar: extraiga las correcciones ascendentes ahora, siguiendo los enlaces de confirmación en cada aviso de Binarly, y realice un seguimiento por ID de aviso, ya que no existen CVE.
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 envió sin ellos; la próxima versión, v2026.10, no saldrá hasta octubre.
Todos los demás ejecutan un dispositivo que otra persona construyó con U-Boot. Para ellos, la solución debe llegar como una actualización de firmware del proveedor del producto. Eso es lo que hay que tener en cuenta.
Esta verificación exacta ha fallado antes. La misma lógica de firma fue afectada meses antes por CVE-2026-33243, que U-Boot parchó en abril; El gestor de arranque barebox relacionado, que utiliza las mismas herramientas de imagen, también se vio afectado.
En ese error, una propiedad destinada solo a enumerar lo que cubre la firma no estaba firmada, por lo que una imagen manipulada podría intercambiarse en partes que nunca fueron verificadas. El asistente detrás de los dos peores errores aquí, fdt_get_name, proviene de libfdt, la biblioteca de árbol de dispositivos aplanados que U-Boot comparte con el kernel de Linux, barebox y otros. El mismo error de devolución no comprobada puede surgir en cualquier lugar donde se utilice el código.
LogoFAIL, que THN cubrió en 2023, era un conjunto de errores de análisis de imágenes en el firmware de la PC que permitían que el código del atacante se ejecutara durante el arranque, antes de que Secure Boot pudiera verificar algo, en casi todas las principales marcas de PC. La firma recibe toda la atención; los insectos siguen aterrizando en las tuberías que corren delante de él.
Y como demostró BootHole en 2020, cuando una falla del gestor de arranque rompió el arranque seguro en todo el ecosistema, escribir el parche es la parte fácil. La parte lenta es introducirlo en millones de dispositivos que ejecutan la copia de U-Boot de otra persona.