Six U-Boot Flaws Expose Routers and Servers to Pre-Boot Code Execution

Firmware security researchers at Binarly have disclosed six previously unknown flaws in U-Boot, the widely deployed open-source bootloader used in home routers, IP cameras, smart-home hubs, and the Baseboard Management Controllers (BMCs) inside data-center servers. Tracked as BRLY-2026-037 through BRLY-2026-042, all six bugs are triggered when U-Boot parses an untrusted Flattened Image Tree (FIT) image before it verifies the package's digital signature, opening a window where a hostile image can subvert the device's chain of trust. No CVEs have been assigned yet, and most of the vulnerable code has lingered in U-Boot since v2013.07, shipping unchanged across more than 50 stable releases and countless vendor forks.

Two of the six flaws are the most severe. Both BRLY-2026-037 and BRLY-2026-038 stem from a single unchecked return value in U-Boot's use of fdt_get_name(), a helper from the libfdt device-tree parsing library. When fed a malformed FIT image, the call returns a null pointer paired with a negative length, and U-Boot passes both straight into further processing. On BRLY-2026-037, that null pointer reaches a memory copy routine and, on hardware where address zero is mapped, produces a stack buffer overflow. On BRLY-2026-038, the negative length is fed into pointer arithmetic that walks backward through memory until it overwrites a saved return address. Either route can hand execution to attacker-controlled code while the device is still booting, well before any secure-boot verification has a chance to run.

The remaining four are denial-of-service class but still disruptive: BRLY-2026-039 and BRLY-2026-041 read out of bounds by trusting attacker-supplied sizes and offsets inside the image, BRLY-2026-040 dereferences a null pointer returned by an older legacy image format handler, and BRLY-2026-042 triggers unbounded recursion when parsing a deeply nested FIT structure, exhausting the stack and crashing the bootloader. Binarly has published standalone proof-of-concept images and reproduction steps for each flaw, validated against stock U-Boot builds. No real-world exploitation has been observed, but because recovery from a bricked bootloader typically requires physical access and an external flasher, defenders and IT teams should treat these as high-priority patches— especially for network appliances and BMCs that ship embedded in production hardware. Admins auditing exposed infrastructure can validate the firmware supply chain on reachable assets using a port scanner and verify vendor update endpoints with a WHOIS lookup to confirm patches are being pulled from legitimate sources.