Six vulnerabilities in U-Boot could run code before checking the signature and compromising the entire chain of trust

Firm's investigators specializing in firmware security Binarly have discovered six vulnerabilities in U-Boot, the start-up charger that acts as the first code executed on such diverse equipment as domestic routers, smart cameras and data center management chips. Gravity does not come only by the possibility of leaving a useless equipment: two of these failures allow you to run code before the signed image is verified, which means that an attacker could, under specific conditions, subvert the entire chain of confidence of the device.

Technically, the problem is concentrated in the management of FIT (Flatted Image Tree), the container that U-Boot uses to group kernel, device tree, ramdisk and other components. The six errors are activated while U-Boot is still parting an unreliable image and before validating its signature. The two most critical (BRLY-2026-037 and BRLY-2026-038, according to Binarly's notices) derive from a call to fdt _ get _ name - from the libfdt library that share U-Boot and the Linux kernel - that on a malformed image returns a null pointer and a negative length, values that the code does not check and that can lead to memory corruption controlled by the attacker.

The rest of the faults come out of the same pattern: trust in offsets and sizes provided by the image, accept old nodes or formats without validation, or allow a nesting depth to exhaust the stack. Some simply cause a locking of the boot charger, but a lock can still leave a team unstarted and require physical intervention to reflect memory.

These vulnerabilities are not new in terms of perspective: Binarly points out that much of that vulnerable code exists in U-Boot since 2013 and remains in dozens of stable branches and in signatures of multiple suppliers. In addition, the failure highlights a repeated lesson in boot safety: the signature is effective only if all the code and the metadata that preceded it are treated safely. Previous incidents such as Boothole and other image parser failures (e.g. LogoFAIL) have shown how pre-verification logic can become the attack route.

Binarly published concept tests and playback steps against U-Boot standard building, and the patches merged into the upstream tree in June. However, the July version of U-Boot (v2026.07) was frozen before they were included and the next release planned for October, v2026.10, is too late for many users. There are not yet CVE assigned to these six failures, so it is crucial to follow them by their BRLY-2026-037 references to BRLY-2026-042 and apply the upstream corrections as soon as possible.

For manufacturers and maintainers of U-Boot-based products the recommendation is immediate: integrate the corrected commitments from the upstream repository, firmly test the boot flows of their platforms and prepare firmware updates for distribution. As the patch already exists in U-Boot but will not appear in the immediate stable release, not waiting for the next community tarball is a sensible decision.

For end-users and administrators, protection requires pragmatic monitoring and mitigation: monitoring supplier security notices to obtain firmware updates, segmenting and restricting access to remote management interfaces (BMC / iDRAC / iLO and the like) and minimizing the exposure of automatic update processes to unreliable networks. In cases where the supplier does not offer patches, it is appropriate to assess temporary measures such as disabling remote updates or isolating the device until there is an official correction.

It is important to stress the real difficulty following the publication of the patch: update millions of devices distributed by multiple suppliers is the real bottle neck. Even when the community fixes the code, the patch must arrive properly tested and deployed by each manufacturer, and often that requires time and resources that not all actors are willing to invest with the necessary urgency.

In terms of detection, these failures are complex: early execution can be left out of the reach of standard operating system security tools. Therefore the defense should prioritize the reduction of delivery vectors: protect updating processes, tighten remote management access and apply integrity controls and firmware recovery (including the need for physical access for recovery where possible).

Those who want to deepen U-Boot and its ecosystem can consult the official documentation at https: / / u-boot.org / and the specification / documentation on device trees in the kernel tree in https: / / www.kernel / doc / html / latest / devicetree /. For historical context on why failure in boot loaders are dangerous, BootHole's research and analysis offer a good reference: https: / / www.eclypsium.com / blog / 2020 / boot-hole /.

In short, these six failures again point to a basic rule: the safety of the boot is as strong as its weakest link in the pre-signature phase. Suppliers, integrators and administrators must act already to apply the upstream corrections, turn on the firmware distribution alert and reduce the ways a malicious image could reach the boot process.