Researchers at firmware security firm **Binarly** have identified six new flaws within **U-Boot**, the foundational program responsible for initiating hardware across a vast array of devices. This includes common consumer electronics like home routers and smart cameras, as well as the sophisticated management chips found in data-center servers. Four of these newly discovered bugs can lead to device crashes. More alarmingly, the remaining two could enable an attacker to inject and execute their own malicious code *before* the device has an opportunity to verify the authenticity of the loaded software image. This pre-OS execution is the critical point. A vulnerability at the bootloader level can compromise the integrity of everything that subsequently loads. All six identified bugs are triggered while **U-Boot** is still processing an untrusted image, prior to any signature verification. ## What Binarly Found **U-Boot** is designed to bundle various boot components—such as the kernel, device tree, and ramdisk—into a single package known as a **FIT (Flattened Image Tree)**. It then performs a digital signature check on this package before relinquishing control. **Binarly** specifically targeted weaknesses in this signature verification process, uncovering six distinct vulnerabilities. The majority of the vulnerable code has been present in **U-Boot** since **v2013.07**, spanning over 50 stable releases. Consequently, these vulnerabilities are also inherited by numerous vendor firmwares built upon **U-Boot**. The bugs are tracked under **Binarly** advisories **BRLY-2026-037** through **BRLY-2026-042**. As of now, no **CVE** identifiers have been assigned. They are categorized into two groups: two critical flaws that could lead to code execution, and four that result in crashes. The code execution vulnerabilities, **BRLY-2026-037** and **BRLY-2026-038**, stem from an unchecked value. **U-Boot** calls `fdt_get_name`, a lookup function from its borrowed device-tree parsing library. When processing a malformed image, this lookup can return a null pointer and a negative length, both of which **U-Boot** uses without proper validation. One bug leverages the null pointer in a memory copy operation, potentially leading to a stack buffer overflow on systems where address zero is mapped. The other feeds the negative length into pointer arithmetic, causing it to overwrite a saved return address. In specific memory layouts, either scenario could grant an attacker control over the device. The remaining four vulnerabilities, **BRLY-2026-039**, **BRLY-2026-040**, **BRLY-2026-041**, and **BRLY-2026-042**, primarily cause the bootloader to crash. **BRLY-2026-039** and **BRLY-2026-041** read beyond the image's boundaries by trusting attacker-controlled size or offset values. **BRLY-2026-040** dereferences a null pointer returned unchecked by an older image format. Finally, **BRLY-2026-042** exhausts the stack due to a deeply nested image structure that triggers an early validation step into excessive recursion. **Binarly** has published proof-of-concept images and detailed reproduction steps for each flaw, demonstrating them against standard **U-Boot** builds. Importantly, there have been no reports of these vulnerabilities being exploited in real-world attacks. Of the six, the two memory-corruption bugs are the most critical. While a crash can disrupt device operation, code execution at the boot stage can fundamentally subvert the device's entire chain of trust. ## The Severity of the Threat In the most severe scenarios, recovering a device that fails to boot may necessitate physical access and direct reflashing of its memory chip. However, code execution is even more perilous. Code running at this early stage operates beneath the operating system, making it virtually undetectable by conventional security tools. An attacker's primary challenge lies in delivering the malicious image. These bugs only become exploitable once a compromised image reaches the boot path, typically requiring either physical access or a privileged foothold on the device. This foothold isn't always local. In prior research concerning **Supermicro** server management controllers, the same **Binarly** researcher demonstrated that an attacker with remote access to the management interface could exploit the device's own update process to flash a malicious image without requiring direct physical interaction with the hardware. ## Recommended Actions As there is currently no stable **U-Boot** release that incorporates these fixes, vendors and maintainers of **U-Boot**-based products are advised to act immediately. They should pull the upstream fixes now, using the commit links provided in each **Binarly** advisory, and track them by advisory ID since **CVEs** are not yet assigned. **U-Boot** merged the six patches in June, but the July release (**v2026.07**) had already finalized in April, thus shipping without them. The next planned release, **v2026.10**, is not anticipated until October. For end-users and organizations operating devices built on **U-Boot**, the resolution will arrive as a firmware update from the respective product vendor. Monitoring for these updates is crucial. This specific signature verification logic has been a point of failure before. Months prior, the same logic was affected by **CVE-2026-33243**, which **U-Boot** patched in April. The related **barebox** bootloader, which utilizes similar image tooling, was also impacted. In that previous bug, a property intended solely to list what the signature covered was itself left unsigned, allowing a tampered image to swap in unverified components. The helper function implicated in the two most severe bugs here, `fdt_get_name`, originates from **libfdt**, the flattened-device-tree library shared by **U-Boot**, the **Linux kernel**, **barebox**, and other projects. This unchecked-return mistake could manifest wherever this shared code is used. Past incidents like **LogoFAIL** in 2023, a series of image-parsing bugs in PC firmware, allowed attacker code to run during boot before **Secure Boot** could initiate checks, impacting nearly every major PC brand. This highlights a recurring theme: while signature verification receives significant attention, vulnerabilities frequently emerge in the underlying plumbing that executes *before* any checks can occur. Furthermore, as demonstrated by **BootHole** in 2020, where a single bootloader flaw compromised **Secure Boot** across the entire ecosystem, developing the patch is often the easier part. The more formidable challenge lies in deploying that patch to the millions of devices running various copies of **U-Boot** globally.