Firmware security firm Binarly disclosed six vulnerabilities in U-Boot, the open-source bootloader used across enterprise server BMCs, networking gear, industrial controllers, and countless embedded Linux devices. Tracked as advisories BRLY-2026-037 through BRLY-2026-042 (no CVE IDs have been assigned as of publication), the bugs live in the code that parses Flattened Image Tree (FIT) firmware images — and critically, all six fire before U-Boot’s signature verification completes. An attacker who can hand a device a malicious firmware image doesn’t need to forge a signature at all; they just need to crash the parser or corrupt memory while it’s still walking the untrusted data.

What happened

FIT images are U-Boot’s standard container format for kernels, device trees, and ramdisks, and they’re supposed to be cryptographically signed so only trusted images boot. Verifying that signature requires U-Boot to first hash the regions of the image — and that hashing step walks the device tree structure inside the FIT image via a function called fdt_find_regions, long before the actual signature check runs.

The root cause behind the two most serious bugs, BRLY-2026-037 and BRLY-2026-038, is a missing NULL check. fdt_find_regions calls fdt_get_name to read node names out of the image, but fdt_get_name returns NULL when it hits an old-format FIT image (version below 0x10) whose node name contains no slash character — a case the code never guards against:

  • BRLY-2026-037: the NULL return value gets passed straight into a strcpy. On the root node this is an immediate crash. On child nodes, the copy targets a stack buffer allocated in the parent function — and because many embedded platforms map the zero page, an attacker who also controls what sits at memory address 0x0 can turn the NULL dereference into a stack-based buffer overflow, and from there into arbitrary code execution.
  • BRLY-2026-038: same failure path, different consequence. When fdt_get_name fails it writes a negative error code into a len variable that the surrounding code uses to advance a pointer through a stack buffer — without checking the sign. A negative length walks the pointer backward instead of forward, producing a stack buffer underflow.

The remaining four bugs are denial-of-service only:

  • BRLY-2026-039: an out-of-bounds read that crashes the device by forcing U-Boot to read past the end of the firmware image.
  • BRLY-2026-040: a separate NULL pointer dereference triggerable with a crafted FIT image.
  • BRLY-2026-041: improper validation of externally stored firmware data, crashing the parser.
  • BRLY-2026-042: unbounded recursion that exhausts the stack.

Binarly’s fix for the two code-execution bugs is a single NULL check on the return value of fdt_get_name — the kind of one-line gap that’s been sitting in production firmware for over a decade.

Impact

U-Boot has carried this vulnerable code path since v2013.07, spanning more than 50 stable releases, and it’s baked into vendor firmware far beyond the upstream project itself — server BMCs (which frequently expose remote firmware-update interfaces), routers and switches, industrial control equipment, and general embedded Linux/IoT hardware. Exploitation doesn’t strictly require physical console access: on a BMC or any device that accepts remote firmware updates, an attacker who has already compromised the management interface (a common outcome of the credential-stuffing and default-password attacks that routinely hit BMC/IPMI interfaces) can upload a crafted FIT image over the network to trigger these bugs. Because the flaws land before signature verification, a properly signed-boot chain provides no protection against them — the parser corrupts memory while still deciding whether to trust the image.

A successful RCE at this layer is about as bad as firmware attacks get: code running below the OS, before Secure Boot’s own verification logic has had a chance to reject anything, with the potential for implants that survive OS reinstalls and are invisible to any endpoint agent running above the bootloader.

Mitigation

Binarly reported all six issues to the U-Boot maintainers, and patches have been merged upstream. That said, upstream fixes don’t reach devices automatically — U-Boot is vendored into each manufacturer’s own firmware builds, so the practical fix requires waiting on (and applying) a vendor firmware update, not just an upstream git pull. Devices that are end-of-life or otherwise no longer receiving firmware support may never get patched.

For now:

  • Inventory devices running U-Boot-based firmware, especially BMCs and network appliances with remote firmware-update paths, and check vendor advisories for BRLY-2026-037 through 042 coverage.
  • Treat BMC/IPMI management interfaces as high-value targets: enforce strong unique credentials, disable remote firmware upload from untrusted networks, and segment management interfaces off the general network.
  • Apply vendor firmware updates as they land; for EOL hardware that won’t be patched, plan replacement or network isolation.
  • Don’t rely on Secure Boot signature verification alone as a mitigation here — the point of these bugs is that they execute before that check runs.

Binarly’s full technical writeup, “Unfit to Boot: Breaking U-Boot’s FIT Signature Verification,” is available on the Binarly blog. No in-the-wild exploitation has been reported as of this writing.