Six U-Boot bugs sit in front of the signature check

Firmware security firm Binarly disclosed six new flaws in U-Boot on Friday, tracked as BRLY-2026-037 through BRLY-2026-042. Two allow code execution before the bootloader has verified anything; four are denial-of-service. The Hacker News’s writeup is the most compact secondary account. No CVE identifiers have been assigned yet.

Analysis. This is a disclosure, not an active-exploitation report. What earns a piece here is not the individual bug count but where all six of them live.

Where the bugs are

All six sit in U-Boot’s parser for the Flattened Image Tree — the FIT format that packages a kernel, device tree, and initrd together, and that the bootloader is supposed to authenticate before it hands control off. Two of the code-execution bugs (BRLY-2026-037 and -038) come from fdt_get_name returning a null pointer or a negative length that the caller trusts. That is the standard shape of the class: an untrusted image supplies a field, a helper returns a sentinel value the calling code was not written to consider, and the pointer arithmetic goes somewhere it should not. The four DoS bugs are variants of the same pattern — out-of-bounds reads on attacker-controlled offsets, a stack-exhaustion via a deeply nested image, an unchecked null in an older image format.

The one detail the Binarly writeup makes load-bearing, and the reason the disclosure is worth reading past the count, is timing. All six bugs are reached while U-Boot is still reading the untrusted image, before it has checked the signature. The FIT signature check is the trust boundary the parser is nominally protecting. The parser is running in front of the trust boundary, not behind it.

That is the design pattern, not a specific bug. Every parser that has to read a header to know whether to trust the payload has this problem, and every parser that gets this problem eventually gets the bugs that follow from it. The U-Boot maintainers know this; the fixes went in.

Where the bugs came from, and when they leave

Binarly’s writeup notes that most of the vulnerable code has been in U-Boot since v2013.07, and that it has ridden across more than fifty stable releases in the thirteen years since. That is not a slur on the U-Boot project — it is the shape of the workload. U-Boot is the small program that starts up home routers, smart cameras, industrial gateways, and the management processors sitting alongside the main CPUs in a lot of server hardware. It is the software people run when the hardware is too constrained or too odd to justify running anything larger. Code paths in software like this do not get exercised or rewritten on any schedule; they get exercised when someone with a fuzzer decides to look.

The patches were merged in June. They missed U-Boot v2026.07, which had already frozen in April. The next tagged release is v2026.10, due in October. That is the fast leg of the pipeline. The slow leg is what happens after — the vendor-specific U-Boot forks that ship in routers and BMCs and cameras, which pick up upstream changes at whatever cadence the SoC vendor and the ODM and the end-product vendor negotiate among themselves. For a lot of shipping devices, the honest answer to “when does the fix arrive” is that it does not, because there is nobody left on the vendor side whose job it is to backport it.

None of that is a reason not to disclose. It is a reason to disclose exactly the way Binarly did — with the maintainers, on a coordinated timeline, and with the details useful to people who ship U-Boot in something.

What the attack looks like, in practice

The Binarly and Hacker News writeups are careful about the vector, and it is worth being careful here too. All six bugs require a malicious image reaching the boot path. Getting an image there usually takes physical access or a privileged foothold on the system already. That does not make the class harmless — Binarly’s earlier work has shown remote management interfaces on servers being abused to write firmware without hardware access, and every honest defender who has walked a rack knows that “the BMC is somewhere on a management VLAN nobody has looked at in years” is a common state.

Read that way, the bugs are the standard shape of a firmware exposure: a wide install base, a design boundary that turns out to be behind the vulnerable code rather than in front of it, and a distribution pipeline that will deliver the fix to some fraction of the affected devices and leave the rest running the same code for another decade. The right response is the boring one — inventory the devices in your environment that boot via U-Boot, note which vendors are actively picking up the v2026.10 tree when it lands, and, for the devices that will not get the fix, tighten access to the management path the malicious image would have to travel down.

The interesting layer sits above that. Trust boundaries that require a parser in front of them are the same mistake in every decade the field has had them, and the answer has always been the same: shrink the code running before the check, or accept that the code running before the check is part of the trust boundary whether it was designed to be or not. U-Boot is unusually visible right now because Binarly has looked at it. Every other small program running before a signature check is still there.

Sourcing

• Binarly Blog: Unfit to Boot: Breaking U-Boot’s FIT signature verification — advisories BRLY-2026-037 through BRLY-2026-042, 2026-07-10
• The Hacker News: Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot — 2026-07-10
• Related: runZero Discloses Seven FatFs Firmware Flaws — 2026-07-03
• Related: Flipper Zero moves to maintenance-only — 2026-07-05