"A bootloader runs before the operating system, so a flaw here can undermine everything that loads after it." That is the plain arithmetic of the risk Binarly's researchers laid out after finding six new flaws in U-Boot, the widely used bootloader that starts hardware ranging from home routers and smart cameras to the management chips inside data‑center servers.
What Binarly found and how the bugs work
Firmware security firm Binarly published six advisories, BRLY-2026-037 through BRLY-2026-042, describing flaws reached while U-Boot is still reading an untrusted FIT (Flattened Image Tree) image — before any signature checks run. Two of the flaws (BRLY-2026-037 and BRLY-2026-038) can lead to code execution at boot; the other four cause crashes.
The two code‑execution issues trace to one unchecked return value from fdt_get_name, a lookup inside libfdt (the flattened‑device‑tree library U-Boot borrows). On a malformed image, fdt_get_name can return a null pointer and a negative length and U-Boot uses both values without checking. One path 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 flaw can hand control to attacker‑supplied code.
Four additional flaws that crash U-Boot
The remaining advisories describe denial‑of‑service conditions. BRLY-2026-039 and BRLY-2026-041 read past the end of the image by trusting a size or offset under attacker control. BRLY-2026-040 dereferences a null pointer returned by an older image format when that value is not checked. BRLY-2026-042 exhausts the stack by using a deeply nested image that drives an early validation step to call itself until the stack is consumed. Binarly published proof‑of‑concept images and step‑by‑step reproduction instructions and demonstrated these against standard U‑Boot builds; no real‑world exploitation has been reported.
Why code execution at boot matters — and how attackers would get there
Binarly emphasizes that the worst outcomes come from code that runs before signature verification. Because the FIT image is parsed before the signature is checked, a successful exploit can subvert the chain of trust that Secure Boot and later checks intend to enforce. Recovering a device that will not boot may require physical access and reflashing its memory chip with a clean image; code execution is worse because it sits beneath the operating system, out of view of ordinary security tooling.
Delivery is the practical constraint: these bugs only bite once a malicious image reaches the boot path, which usually requires physical access or a privileged foothold. That foothold is not always local. Binarly notes earlier research on Supermicro's server management controllers showed an attacker with remote access to the management interface could abuse the device's own update process to flash a malicious image without physically touching the hardware.
Where fixes stand and what vendors should do
U-Boot merged patches for these six bugs in June. However, the v2026.07 release had already frozen in April and shipped without them; the next scheduled release, v2026.10, is not due until October. No stable U‑Boot release containing the fixes is available yet, and no CVE identifiers have been assigned to BRLY-2026-037 through BRLY-2026-042.
Binarly's guidance is explicit: vendors and maintainers should not wait for the next upstream release — pull the upstream fixes now, following the commit links in each Binarly advisory, and track them by advisory ID. For device owners, the fix must arrive as a firmware update from the product vendor; everyone who runs a device built on U‑Boot should watch for those vendor updates.
What this means for U‑Boot maintainers, data‑center operators, and device owners
- U‑Boot maintainers and vendor firmware teams: prioritize the two memory‑corruption fixes (BRLY-2026-037 and BRLY-2026-038) because they enable code execution at boot. Backport or cherry‑pick the merged commits now rather than waiting for v2026.10, and track Binarly advisories by ID since CVEs are not yet assigned.
- Data‑center and server management operators: review management‑controller update paths and remote flashing mechanisms. Earlier Supermicro research shows remote update processes can be abused to place malicious images into the boot path without physical access.
- Device owners and product procurement teams: expect rollout lag. As the advisory notes, prior incidents (for example, CVE‑2026‑33243 and the broader LogoFAIL and BootHole histories) show that patch creation is fast compared with getting firmware installed across millions of deployed devices.
There is a cleaner technical fix merged upstream, but history offers a blunt reminder: as BootHole observed, writing the patch is usually the easy part; getting it onto the millions of devices running someone else's copy of U‑Boot is the slow part. Vendors, operators and owners now face that familiar test of patch management and supply‑chain coordination ahead of the October release window.
