La seguridad del proceso de arranque vuelve a situarse en el centro de la ciberseguridad tras el descubrimiento de seis nuevas vulnerabilidades críticas en U-Boot, uno de los bootloaders de código abierto más utilizados del mundo. Investigadores de la empresa especializada en seguridad de firmware Binarly revelaron que estos fallos podrían permitir desde bloqueos completos de dispositivos hasta la ejecución arbitraria de código antes de que el sistema operativo verifique la autenticidad del software, comprometiendo así toda la cadena de confianza del proceso de inicio.
El hallazgo resulta especialmente relevante porque U-Boot es el gestor de arranque empleado por millones de dispositivos embebidos e infraestructuras críticas, incluyendo routers domésticos, cámaras IP, dispositivos IoT, equipos industriales, sistemas automotrices, plataformas ARM y controladores de administración de servidores (BMC) presentes en centros de datos.
Aunque hasta el momento no existen evidencias de explotación activa, la naturaleza de estas vulnerabilidades convierte el problema en una prioridad para fabricantes, integradores y administradores de sistemas, especialmente porque el código vulnerable ha permanecido presente durante más de una década en decenas de versiones estables del proyecto.
¿Qué es U-Boot y por qué es tan importante?
U-Boot (Universal Boot Loader) es uno de los cargadores de arranque (bootloaders) más populares dentro del ecosistema Linux y de los sistemas embebidos.
Su función consiste en iniciar el hardware del dispositivo, preparar la memoria, cargar el kernel del sistema operativo y verificar que el software que se ejecutará posteriormente sea legítimo.
En términos sencillos, U-Boot actúa como el primer componente de software que entra en funcionamiento tras encender un dispositivo.
Precisamente por ejecutarse antes que el sistema operativo, cualquier vulnerabilidad en esta fase puede permitir que un atacante comprometa completamente el equipo incluso antes de que entren en funcionamiento mecanismos de protección como:
- Secure Boot.
- Controles del sistema operativo.
- Soluciones EDR.
- Antivirus.
- Sistemas de monitorización.
Por este motivo, las vulnerabilidades en gestores de arranque suelen considerarse de máxima criticidad.
Binarly descubre seis nuevas vulnerabilidades
Los investigadores de Binarly centraron su análisis en el mecanismo mediante el cual U-Boot procesa las denominadas Flattened Image Tree (FIT).
Una imagen FIT agrupa varios componentes esenciales del proceso de arranque, entre ellos:
- Kernel Linux.
- Device Tree.
- RAM Disk (initramfs).
- Configuraciones de arranque.
- Componentes adicionales del firmware.
Antes de iniciar el sistema operativo, U-Boot verifica la firma digital de esta imagen para garantizar que no ha sido modificada.
Sin embargo, los investigadores descubrieron que el análisis de la imagen se realiza antes de completar completamente la validación criptográfica, permitiendo que un archivo especialmente manipulado active diversas vulnerabilidades.
Dos fallos permiten ejecutar código arbitrario
Las vulnerabilidades más graves corresponden a los identificadores internos:
- BRLY-2026-037
- BRLY-2026-038
Ambas afectan al tratamiento de datos obtenidos mediante la función fdt_get_name(), perteneciente a la biblioteca libfdt, ampliamente utilizada por proyectos como:
- U-Boot.
- Linux Kernel.
- Barebox.
- Otros cargadores de arranque.
Cuando una imagen FIT especialmente manipulada devuelve valores inesperados, la función puede generar:
- Un puntero nulo.
- Una longitud negativa.
El problema es que U-Boot utiliza estos valores sin realizar comprobaciones previas.
Desbordamiento de memoria
En uno de los escenarios, el puntero nulo termina utilizándose durante una operación de copia de memoria.
En determinados dispositivos donde la dirección cero permanece accesible, esto puede derivar en un desbordamiento del búfer de pila (Stack Buffer Overflow).
Sobrescritura de direcciones de retorno
La segunda vulnerabilidad utiliza la longitud negativa para alterar operaciones aritméticas sobre punteros.
Como resultado, el proceso puede sobrescribir direcciones de retorno almacenadas en la pila, permitiendo que un atacante redirija completamente el flujo de ejecución hacia código malicioso.
En ambos casos, el objetivo final consiste en ejecutar código arbitrario incluso antes de que el sistema operativo inicie su carga.
Cuatro vulnerabilidades provocan bloqueos del dispositivo
Las otras cuatro vulnerabilidades descubiertas producen distintos tipos de denegación de servicio durante el proceso de arranque.
BRLY-2026-039 y BRLY-2026-041
Estas fallas permiten leer datos fuera de los límites de la imagen debido a tamaños y desplazamientos manipulados por el atacante.
BRLY-2026-040
Esta vulnerabilidad provoca la desreferenciación de un puntero nulo generado por un formato antiguo de imagen que no es validado correctamente.
BRLY-2026-042
El último fallo genera un agotamiento completo de la pila mediante imágenes FIT profundamente anidadas.
La validación recursiva consume toda la memoria disponible hasta provocar el bloqueo del bootloader.
El verdadero riesgo está antes del sistema operativo
Aunque los cuatro fallos de denegación de servicio pueden dejar un dispositivo inutilizable temporalmente, Binarly considera mucho más peligrosas las dos vulnerabilidades de ejecución de código.
Cuando un atacante consigue ejecutar instrucciones durante el proceso de arranque obtiene una posición extremadamente privilegiada.
Desde ese nivel podría:
- Modificar el proceso de inicio.
- Alterar el kernel antes de cargarlo.
- Instalar malware persistente.
- Eludir Secure Boot.
- Ocultar código malicioso al sistema operativo.
- Comprometer toda la cadena de confianza.
Este tipo de ataques resulta especialmente difícil de detectar porque ocurre antes de que cualquier solución tradicional de seguridad entre en funcionamiento.
¿Qué tan fácil es explotar estas vulnerabilidades?
Afortunadamente, la explotación no resulta sencilla.
Para que el ataque tenga éxito es necesario introducir una imagen FIT manipulada en el proceso de arranque del dispositivo.
Esto normalmente requiere:
- Acceso físico.
- Acceso privilegiado al firmware.
- Control sobre el proceso de actualización.
- Compromiso previo del sistema.
Sin embargo, Binarly recuerda que el acceso físico no siempre es imprescindible.
En investigaciones anteriores sobre Supermicro, los mismos investigadores demostraron que era posible aprovechar interfaces remotas de administración (BMC) para cargar firmware malicioso sin necesidad de tocar físicamente el servidor.
Este precedente demuestra que una vulnerabilidad de arranque puede convertirse en una amenaza remota cuando existen otros puntos de entrada.
Más de una década de código vulnerable
Uno de los aspectos más preocupantes del informe es que el código afectado lleva presente desde U-Boot 2013.07.
Según Binarly, las vulnerabilidades han permanecido en:
- Más de 50 versiones estables.
- Numerosos firmwares personalizados de fabricantes.
- Miles de productos comerciales basados en U-Boot.
Esto significa que la superficie potencialmente afectada podría alcanzar millones de dispositivos desplegados en todo el mundo.
Todavía no existen identificadores CVE
Las vulnerabilidades fueron publicadas como:
- BRLY-2026-037
- BRLY-2026-038
- BRLY-2026-039
- BRLY-2026-040
- BRLY-2026-041
- BRLY-2026-042
Hasta el momento no han recibido identificadores CVE, por lo que fabricantes y administradores deberán seguir los avisos publicados directamente por Binarly.
Los parches ya existen, pero tardarán en llegar
El proyecto U-Boot integró oficialmente las correcciones durante el mes de junio.
No obstante, existe un inconveniente importante.
La versión estable v2026.07 ya había cerrado su ciclo de desarrollo en abril.
Como consecuencia, dicha versión fue publicada sin incluir los nuevos parches.
La próxima versión estable que incorporará todas las correcciones será U-Boot v2026.10, prevista para octubre.
Mientras tanto, los fabricantes deberán integrar manualmente los cambios publicados en el repositorio oficial.
Un problema recurrente en la seguridad del arranque
Este descubrimiento no constituye un caso aislado.
En los últimos años han aparecido varias vulnerabilidades similares que han afectado al ecosistema del arranque seguro.
Entre las más relevantes destacan:
BootHole
Descubierta en 2020, esta vulnerabilidad comprometía Secure Boot en millones de dispositivos mediante un fallo en el gestor GRUB2.
LogoFAIL
En 2023, investigadores descubrieron múltiples vulnerabilidades en el análisis de imágenes del firmware UEFI que permitían ejecutar código antes incluso de que Secure Boot iniciara su proceso de validación.
CVE-2026-33243
Hace apenas unos meses, U-Boot corrigió otro problema relacionado con la validación de firmas digitales que permitía modificar partes de una imagen FIT sin que fueran verificadas correctamente.
Todos estos casos evidencian una realidad: la seguridad del proceso de arranque continúa siendo uno de los eslabones más complejos y sensibles dentro de cualquier plataforma informática.
Recomendaciones para fabricantes y administradores
Ante la ausencia de una versión estable con las correcciones, Binarly recomienda actuar de inmediato:
- Integrar manualmente los parches publicados por el proyecto U-Boot.
- Seguir los identificadores BRLY mientras se asignan los correspondientes CVE.
- Supervisar las actualizaciones de firmware ofrecidas por cada fabricante.
- Limitar el acceso al proceso de actualización del firmware.
- Restringir el acceso físico a dispositivos críticos.
- Verificar la autenticidad de todas las imágenes de arranque antes de desplegarlas.
Los usuarios finales que utilicen dispositivos comerciales deberán esperar a que el fabricante distribuya nuevas versiones del firmware con las correcciones incorporadas.
En fin…
Las seis nuevas vulnerabilidades descubiertas en U-Boot ponen de manifiesto la importancia de proteger todas las etapas del proceso de arranque, especialmente aquellas que se ejecutan antes de que entren en funcionamiento el sistema operativo y los mecanismos tradicionales de seguridad. Los dos fallos que permiten la ejecución arbitraria de código representan el mayor riesgo, ya que podrían comprometer por completo la cadena de confianza y facilitar la instalación de malware persistente difícil de detectar.
Aunque actualmente no existen evidencias de explotación activa, la amplia adopción de U-Boot en millones de dispositivos convierte este hallazgo en un desafío significativo para fabricantes y organizaciones. La rápida integración de los parches, la distribución de actualizaciones de firmware y la implementación de controles estrictos sobre el proceso de arranque serán fundamentales para reducir el riesgo y evitar que estas vulnerabilidades sean aprovechadas en futuros ataques dirigidos contra infraestructuras críticas, dispositivos IoT y entornos empresariales.
Fuente: The Hacker News
