Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot

Summary

Researchers at Binarly have discovered six critical vulnerabilities in U-Boot, a bootloader used in a wide range of devices from routers to servers. Four of these flaws can cause a device to crash, while the other two allow for arbitrary code execution before the operating system loads, potentially compromising the entire system's chain of trust. The vulnerabilities have existed in U-Boot for years and affect numerous vendor firmwares.

Full text

Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot Swati KhandelwalJul 10, 2026Firmware Security / Vulnerability Researchers at firmware security firm Binarly have found six new flaws in U-Boot, the small program that starts up hardware as varied as home routers, smart cameras, and the management chips inside data-center servers. Four of the bugs can crash a device. The other two could let an attacker who slips a malicious image in front of the bootloader run their own code, before the device has confirmed that the software is genuine. That last part is the point. A bootloader runs before the operating system, so a flaw here can undermine everything that loads after it. All six bugs are reached while U-Boot is still reading an untrusted image, before it has checked the signature. What Binarly found U-Boot can bundle a kernel, device tree, ramdisk, and other boot components into one package, a FIT (Flattened Image Tree), and it checks that package's digital signature before handing over control. Binarly went looking for weak spots in that check and found six. Most of the vulnerable code has been in U-Boot since v2013.07, Binarly says, across more than 50 stable releases, and it also lives in the many vendor firmwares built on top of U-Boot. The bugs are tracked as Binarly advisories BRLY-2026-037 through BRLY-2026-042. No CVE identifiers have been assigned yet. They fall into two groups: two that could run code, and four that only crash. The two are BRLY-2026-037 and BRLY-2026-038, and both trace to one unchecked value. U-Boot calls fdt_get_name, a lookup in the device-tree parsing library it borrows, and on a malformed image, that lookup returns a null pointer and a negative length. U-Boot uses both without checking either. One bug 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 one can hand control to code the attacker-supplied. The other four only crash the bootloader. BRLY-2026-039 and BRLY-2026-041 read past the end of the image by trusting a size or offset that the attacker controls. BRLY-2026-040 dereferences a null pointer that an older image format hands back unchecked. BRLY-2026-042 exhausts the stack, set off by a deeply nested image that drives an early validation step to call itself until it runs out. Binarly published a proof-of-concept image and reproduction steps for each flaw and demonstrated them against standard U-Boot builds. No exploitation in real attacks has been reported. Of the six, the two memory-corruption bugs are the ones to prioritize: a crash can knock a device offline, but code execution at boot could subvert its entire chain of trust. How bad it gets In the worst case, recovering a device that will not boot means physical access and reflashing its memory chip with a clean image. Code execution is worse. Code that runs this early sits below the operating system, where ordinary security tools may not see it. The catch for an attacker is delivery: these bugs only bite once a malicious image reaches the boot path, which usually takes physical access or a privileged foothold. That foothold is not always local. In earlier work on Supermicro's server management controllers, the same Binarly researcher showed that an attacker with remote access to the management interface could abuse the device's own update process to flash a malicious image, without touching the hardware. What to do There is no stable release with the fix yet, so vendors and maintainers of U-Boot-based products should not wait: pull the upstream fixes now, following the commit links in each Binarly advisory, and track them by advisory ID, since no CVEs exist. U-Boot merged the six patches in June, but the July release (v2026.07) had already frozen in April, so it shipped without them; the next release, v2026.10, is not due until October. Everyone else runs a device someone else built on U-Boot. For them, the fix has to arrive as a firmware update from the product vendor. That is what to watch for. This exact check has failed before. The same signature logic was hit months earlier by CVE-2026-33243, which U-Boot patched in April; the related barebox bootloader, which uses the same image tooling, was hit too. In that bug, a property meant only to list what the signature covers was not itself signed, so a tampered image could swap in parts that were never verified. The helper behind the two worst bugs here, fdt_get_name, comes from libfdt, the flattened-device-tree library U-Boot shares with the Linux kernel, barebox, and others. The same unchecked-return mistake can surface anywhere that code is used. LogoFAIL, which THN covered in 2023, was a set of image-parsing bugs in PC firmware that let attacker code run during boot, before Secure Boot could check anything, across nearly every major PC brand. The signature gets all the attention; the bugs keep landing in the plumbing that runs before it. And as BootHole showed in 2020, when one bootloader flaw broke Secure Boot across the ecosystem, writing the patch is the easy part. The slow part is getting it onto the millions of devices running someone else's copy of U-Boot. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post. SHARE     Tweet Share Share Share SHARE  Bootloader Security, Code Execution, denial of service, Embedded Security, Firmware Security, iot security, Memory Corruption, Secure Boot, server security, Vulnerability ⚡ Top Stories This Week ThreatsDay: AI Compute Hijacking, Apple Email Flaw, BlueHammer Ransomware + 14 Stories Chrome Ad Blocker with 10M+ Installs Found with Dormant Script Injection Capability New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards FBI Warns Russian Intelligence Hackers Target Signal Backup Recovery Keys Public PoC Released for Critical libssh2 CVE-2026-55200 Client-Side SSH Flaw Microsoft Removes 119 Edge Extensions That Hid Malware in Images and Fonts ⚡ Weekly Recap: Linux Kernel Flaws, AI Malware Tricks, Turla Backdoor, Infostealers and More Mustang Panda Uses Zoho WorkDrive as Command Channel in Indian Government Attacks WhatsApp is Finally Getting Usernames to Help Keep Phone Numbers Private Oracle E-Business Suite Flaw CVE-2026-46817 Actively Exploited in the Wild New BioShocking Attack Tricks AI Browsers Into Leaking User Credentials AirDrop and Quick Share Flaws Let Nearby Attackers Trigger Crashes and Bypass Checks 282 iOS AI Apps Leak API Keys and Open AI Proxy Access in Network Traffic Study GuardFall Exposes Open-Source AI Coding Agents to Decades-Old Shell Injection Risks Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data RustDuck Botnet Rebuilds in Rust to Hijack Routers and Servers for DDoS ⭐ Featured Resources What 200+ Security Teams Reveal About Using IP Intelligence in 2026 Get Hands-On SANS Training for Today’s Cyber Defense and Offensive Security Challenges See What’s Really Exposed Across Your IT, OT, IoT, Cloud, and Mobile Assets Get Gartner’s Guide to AI Agent Supervision and Runtime Controls

Entities