Researchers at firmware security firm Binarly have found six new flaws in U-Boot, the small program that starts up hardware as varied as home routers, smart cameras, and the management chips inside data-center servers.
Four of the bugs can crash a device. The other two could let an attacker who slips a malicious image in front of the bootloader run their own code, before the device has confirmed that the software is genuine.
That last part is the point. A bootloader runs before the operating system, so a flaw here can undermine everything that loads after it. All six bugs are reached while U-Boot is still reading an untrusted image, before it has checked the signature.
What Binarly found
U-Boot can bundle a kernel, device tree, ramdisk, and other boot components into one package, a FIT (Flattened Image Tree), and it checks that package’s digital signature before handing over control.
Binarly went looking for weak spots in that check and found six. Most of the vulnerable code has been in U-Boot since v2013.07, Binarly says, across more than 50 stable releases, and it also lives in the many vendor firmwares built on top of U-Boot.
The bugs are tracked as Binarly advisories BRLY-2026-037 through BRLY-2026-042. No CVE identifiers have been assigned yet. They fall into two groups: two that could run code, and four that only crash.
The two are BRLY-2026-037 and BRLY-2026-038, and both trace to one unchecked value. U-Boot calls fdt_get_name, a lookup in the device-tree parsing library it borrows, and on a malformed image, that lookup returns a null pointer and a negative length. U-Boot uses both without checking either.
One bug follows the null pointer into a memory copy that, on devices where address zero is mapped, becomes a stack buffer overflow. The other feeds the negative length into pointer arithmetic that walks backward until it overwrites a saved return address. In the right memory layout, either one can hand control to code the attacker-supplied.
The other four only crash the bootloader. BRLY-2026-039 and BRLY-2026-041 read past the end of the image by trusting a size or offset that the attacker controls. BRLY-2026-040 dereferences a null pointer that an older image format hands back unchecked. BRLY-2026-042 exhausts the stack, set off by a deeply nested image that drives an early validation step to call itself until it runs out.
Binarly published a proof-of-concept image and reproduction steps for each flaw and demonstrated them against standard U-Boot builds. No exploitation in real attacks has been reported.
Of the six, the two memory-corruption bugs are the ones to prioritize: a crash can knock a device offline, but code execution at boot could subvert its entire chain of trust.
How bad it gets
In the worst case, recovering a device that will not boot means physical access and reflashing its memory chip with a clean image. Code execution is worse. Code that runs this early sits below the operating system, where ordinary security tools may not see it.
The catch for an attacker is delivery: these bugs only bite once a malicious image reaches the boot path, which usually takes physical access or a privileged foothold. That foothold is not always local.
In earlier work on Supermicro’s server management controllers, the same Binarly researcher showed that an attacker with remote access to the management interface could abuse the device’s own update process to flash a malicious image, without touching the hardware.
What to do
There is no stable release with the fix yet, so vendors and maintainers of U-Boot-based products should not wait: pull the upstream fixes now, following the commit links in each Binarly advisory, and track them by advisory ID, since no CVEs exist.
U-Boot merged the six patches in June, but the July release (v2026.07) had already frozen in April, so it shipped without them; the next release, v2026.10, is not due until October.
Everyone else runs a device someone else built on U-Boot. For them, the fix has to arrive as a firmware update from the product vendor. That is what to watch for.
This exact check has failed before. The same signature logic was hit months earlier by CVE-2026-33243, which U-Boot patched in April; the related barebox bootloader, which uses the same image tooling, was hit too.
In that bug, a property meant only to list what the signature covers was not itself signed, so a tampered image could swap in parts that were never verified. The helper behind the two worst bugs here, fdt_get_name, comes from libfdt, the flattened-device-tree library U-Boot shares with the Linux kernel, barebox, and others. The same unchecked-return mistake can surface anywhere that code is used.
LogoFAIL, which THN covered in 2023, was a set of image-parsing bugs in PC firmware that let attacker code run during boot, before Secure Boot could check anything, across nearly every major PC brand. The signature gets all the attention; the bugs keep landing in the plumbing that runs before it.
And as BootHole showed in 2020, when one bootloader flaw broke Secure Boot across the ecosystem, writing the patch is the easy part. The slow part is getting it onto the millions of devices running someone else’s copy of U-Boot.
