Security researchers uncovered six vulnerabilities in U-Boot, the open-source bootloader that powers everything from network routers and industrial controllers to enterprise server management boards. The issues strike at the heart of its FIT image signature verification, a mechanism meant to guarantee that only trusted firmware loads during device startup. Four bugs trigger device crashes. Two open pathways to code execution before any operating system or security software can intervene.
The flaws surfaced from a close examination by experts at Binarly. They focused on code that has remained largely unchanged since version 2013.07, spanning more than fifty stable releases. Because so many hardware makers build custom firmware on top of U-Boot, the exposure reaches far across consumer, enterprise, and critical infrastructure devices.
“Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely,” the firm stated in its detailed technical report. (Binarly)
The vulnerabilities carry internal tracking labels BRLY-2026-037 through BRLY-2026-042. No CVE numbers have been issued yet. They all activate while U-Boot parses an untrusted FIT package, well before the digital signature check completes. That timing matters. Any compromise here sits beneath the operating system, where detection tools rarely reach and persistence becomes trivial.
BRLY-2026-037 and BRLY-2026-038 stand out. Both stem from the same unchecked return value of fdt_get_name, a function borrowed from the libfdt device-tree library. On a crafted image, the call yields a null pointer paired with a negative length. U-Boot proceeds anyway. One path leads to a stack buffer overflow when address zero is mapped. The other performs pointer arithmetic that walks backward, overwriting a saved return address on the stack. With the right memory layout, control flows to attacker code.
The remaining four produce denial-of-service conditions. BRLY-2026-039 trusts an attacker-controlled size on the hashed-strings property and reads past the end of the image. BRLY-2026-041 mishandles external data properties whose offset and size fields point outside valid bounds or specify enormous values. BRLY-2026-040 fails to check a null return from an older FDT format before dereferencing it. BRLY-2026-042 triggers unbounded recursion through deeply nested structures until the stack collapses.
Binarly supplied proof-of-concept FIT images and step-by-step reproduction instructions for each case. The firm tested them successfully against standard U-Boot builds on QEMU. No active exploitation in the wild has been confirmed. Still, the potential consequences command attention.
A simple crash forces hardware offline until someone with physical access reflashes clean firmware. Code execution delivers worse. An attacker could disable security features, modify boot parameters, or drop persistent malware that survives OS reinstalls. Because the code runs so early, traditional endpoint defenses stay blind. Firmware-level rootkits become realistic.
Delivery often requires physical access or an existing privileged foothold. Yet that bar isn’t absolute. In prior research on Supermicro server management controllers, Binarly demonstrated how remote access to a management interface could let an attacker abuse the update mechanism itself to flash malicious images without ever touching hardware. (The Hacker News)
Similar themes appear in other recent discoveries. A separate integer underflow tracked as CVE-2026-29008 affects U-Boot through 2026.04-rc3. It lets a network-adjacent attacker crash the bootloader with a single malformed TCP SYN+ACK packet, potentially preventing devices from booting altogether. (BleepingComputer) That report, published hours after the Binarly disclosure, highlights how network-facing boot components continue to draw scrutiny.
The FIT signature bypass pattern itself isn’t new. Earlier this year CVE-2026-46728 allowed FIT verification to be bypassed because the “hashed-nodes” property was omitted from the hash calculation. U-Boot addressed it before version 2026.04. The related barebox bootloader faced parallel problems. These incidents show that signature logic contains subtle gaps that keep surfacing.
Libfdt, the shared library at the center of several bugs here, also ships inside the Linux kernel and other bootloaders. An unchecked return value in fdt_get_name could therefore appear elsewhere. The pattern echoes past incidents such as LogoFAIL, where image-parsing bugs in UEFI firmware let malicious graphics execute before Secure Boot validation. Or BootHole, the 2020 GRUB2 vulnerability that broke Secure Boot protections across millions of systems. Patches arrived. Deployment lagged.
U-Boot maintainers merged fixes for the six Binarly issues in June. Yet the v2026.07 release had frozen months earlier and shipped without them. The next stable version, v2026.10, remains months away. Device vendors must therefore backport the upstream commits themselves, tracking by BRLY advisory ID rather than CVE number. End users depend on those vendors to issue firmware updates. Some may never arrive for legacy products.
The fixes themselves add straightforward checks. Validate the return of fdt_get_name. Bound sizes and offsets. Limit recursion depth to 32 levels. Add a depth counter to fdt_check_no_at. Simple in theory. But every downstream fork must integrate them, test them, and ship them. History suggests that process takes time, leaving windows of exposure.
Enterprise security teams managing fleets of embedded devices should inventory U-Boot versions now. Ask vendors for patching timelines. Where possible, restrict physical and management-interface access that could deliver malicious images. Monitor for unexpected boot failures that might signal attempted crashes.
Researchers continue to turn over bootloader code because the payoff is high. A flaw here can undermine every protection layered above it. The six Binarly findings, paired with concurrent network-related bugs like CVE-2026-29008, underscore that boot-time software still holds latent weaknesses. Attackers notice. Defenders must move faster.
So the pressure falls on maintainers, vendors, and operators. Pull the patches. Test rigorously. Update widely. Because once malicious code slips past signature verification and gains execution at boot, the rest of the security stack may never get a chance to respond.
WebProNews is an iEntry Publication