Binarly Finds Six U-Boot CVEs That Break Secure Boot on 50+ Firmware

Binarly disclosed six flaws in U-Boot's FIT signature verification subsystem, including two RCEs that bypass Secure Boot across more than 50 firmware releases.
Table of Contents
    Add a header to begin generating the table of contents

    Firmware security firm Binarly disclosed six vulnerabilities in U-Boot’s FIT (Flattened Image Tree) signature verification subsystem — the cryptographic check that runs during device boot — including two that allow arbitrary code execution and bypass Secure Boot entirely. The flaws affect more than 50 stable U-Boot releases and have been present since version v2013.07, leaving home routers, IoT devices, smart cameras, and server baseboard management controllers exposed to pre-OS compromise that persists invisibly below the operating system layer.

    Six Flaws in U-Boot’s FIT Signature Verification: Two RCEs and Four DoS Conditions

    Binarly assigned internal tracking identifiers BRLY-2026-037 through BRLY-2026-042 to the six vulnerabilities. CVE numbers had not been assigned at the time of publication. The vulnerabilities are located specifically in the FIT signature verification code — the component responsible for confirming that boot images are cryptographically signed before the device loads them. All six affect more than 50 stable U-Boot releases, and the vulnerable code traces back to version v2013.07, meaning the flaws have existed in deployable U-Boot releases for over a decade.

    Two RCEs in FIT Signature Verification That Allow Code Execution Before the OS Loads

    Two of the six vulnerabilities allow arbitrary code execution during the boot image verification process. Exploiting either flaw gives an attacker code execution at the bootloader stage — before the operating system loads, before any OS-level security controls initialize, and before any endpoint detection tools are active. Code executed at this stage operates at the highest trust level in the device’s boot chain and can modify what the device subsequently loads as its operating system. The remaining four vulnerabilities cause denial-of-service conditions rather than code execution, but they can still disrupt device availability by preventing normal boot completion.

    Home Routers, IoT Cameras, and BMCs Across 50-Plus Firmware Releases Affected

    The device classes affected span the most widely deployed categories of embedded hardware: home routers, IoT devices, smart cameras, and server baseboard management controllers (BMCs). BMCs are particularly high-value targets — they provide out-of-band management access to servers and operate independently of the main OS, meaning a compromised BMC gives an attacker persistent access to a server that survives full OS reinstallation. Home routers and IoT devices represent the opposite end of the update cadence spectrum: devices that consumers rarely update and that OEMs sometimes stop patching within a few years of product release.

    Why Pre-OS Compromise via U-Boot Flaws Is Exceptionally Difficult to Detect and Remove

    A successful exploit of either RCE vulnerability places attacker code at the bootloader layer — below the operating system, below any installed security tooling, and below the visibility layer of standard forensic analysis. Persistence achieved at this layer survives OS reinstallation because the bootloader itself is not replaced during a standard OS re-image. Removing a bootloader-level implant requires physical hardware access or a full firmware reflash that overwrites the bootloader partition — a remediation step that most organizations have never needed to perform and that requires specialized tooling or manufacturer support.

    Patches Merged Into U-Boot Master Branch; OEM Firmware Updates Required for End Devices

    All six patches have been accepted and merged into U-Boot’s master branch. However, the U-Boot project’s patch release does not directly result in updated firmware for the hundreds of device models that incorporate U-Boot. Each device manufacturer must take the upstream patch, integrate it into their device-specific firmware, test the resulting build, and release it through their own update channels. This multi-step OEM pipeline introduces a delay between Binarly’s disclosure and the point at which any given device receives a patched firmware version. Devices from manufacturers that have discontinued firmware support for older models may never receive a patch.

    The Embedded Device Update Gap That Leaves Millions Exposed

    The fundamental exposure created by these six vulnerabilities is not the vulnerabilities themselves but the update gap between U-Boot’s upstream patch availability and deployed device firmware versions. A router or IoT camera running a U-Boot version released between v2013.07 and the affected stable releases is vulnerable regardless of what OS or application software runs on top of it. End users rarely receive proactive notifications about bootloader-level patches, and the update process for embedded devices is significantly more complex than running a package manager update.

    Binarly’s disclosure puts pressure on device OEMs to prioritize firmware releases that include the U-Boot patches. For organizations running server BMCs based on vulnerable U-Boot versions, direct engagement with hardware vendors to assess patch availability and timeline is warranted given the persistent, OS-invisible nature of a successful compromise at the bootloader stage.

    Related Posts