U-Boot bootloader security for embedded firmware, explained

Das U-Boot ("the Universal Boot Loader", almost always just called U-Boot) is the open-source, second-stage bootloader that runs on the large majority of embedded Linux, IoT and industrial devices between power-on and the operating system kernel starting. Bootloader security matters specifically because U-Boot runs earlier and at a higher privilege level than anything the OS can see or defend — U-Boot's own Verified Boot documentation frames the goal as verifying "all software loaded into a machine during the boot process to ensure that it is authorised and correct for that machine," starting from the moment of reset. A device with U-Boot left at its permissive defaults — autoboot interruptible by anyone with serial or UART access, environment variables writable from the running OS, no signature check on the next stage — turns a few seconds of physical or local access into persistent control of everything that boots afterward, including a chain that otherwise looks secure from the OS up.

U-Boot's Flat Image Tree (FIT) format supports both hashing (detects corruption) and signing (detects substitution): U-Boot's own FIT Signature Verification documentation describes the procedure as hash an image in the FIT, sign the hash with a private key, and store the signature in the FIT — verified at boot by reading the FIT, obtaining the public key, and checking the signature against a freshly computed hash. Two real CVEs show where this goes wrong in practice rather than in theory. CVE-2020-10648 is described by NVD as allowing "attackers to bypass verified boot restrictions and subsequently boot arbitrary images by providing a crafted FIT image to a system configured to boot the default configuration" — the check existed but a crafted image could still evade it. CVE-2018-3968, found by Cisco Talos, is older and structural: NVD describes it as a flaw in versions 2013.07-rc1 to 2014.07-rc2 that "lack proper FIT signature enforcement, which allows an attacker to bypass U-Boot's verified boot and execute an unsigned kernel, embedded in a legacy image format" — a second, unsigned image format sitting alongside the signed one. U-Boot's current signature documentation reflects that exact lesson learned: it now warns that relying on signed FIT images requires the legacy image format to be explicitly disabled, since it is not covered by the signature check at all.

U-Boot's own Environment Variables documentation defines the `bootdelay` variable as the delay "before automatically running bootcmd," with three distinct behaviours: a positive value autoboots but "can be stopped by key input," `-1` "disable[s] autoboot" entirely, and `-2` autoboots "with no delay and not check[s] for abort." The first setting is what most devices ship with, and it is the problem: any value that leaves a window for key input leaves a window for a local attacker with UART or serial access to drop into the U-Boot console and run arbitrary boot commands — set `bootargs` to disable kernel security features, point `bootcmd` at an attacker-supplied image over network or USB, or dump memory directly. U-Boot's `CONFIG_AUTOBOOT_KEYED` mechanism raises the bar by requiring a specific stop string (optionally a SHA-256 or crypt-hashed password) instead of any keypress, and `-1`/`-2` remove the interactive window outright at the cost of removing a legitimate recovery path too — the real engineering tradeoff is recovery access versus attack surface, not a free hardening step.

Beyond the two FIT-signature bypasses above, CISA's ICS advisory ICSA-25-343-01 (Update A) documents a different class of bootloader weakness entirely: CVE-2025-24857, an "improper access control for volatile memory containing boot code" affecting U-Boot before version 2017.11 on several Qualcomm IPQ-series chipsets used in networking equipment. The mechanism CISA describes does not touch FIT signatures at all — it is about memory protection: an attacker able to tamper with boot code sitting in volatile memory can have that tampered code execute on the next boot cycle, at bootloader privilege. CISA's advisory recommends upgrading to U-Boot v2025.4 or later and, since the attack vector is physical, pairs the software fix with physical hardening (securing or epoxy-sealing exposed ports). Taken together with CVE-2018-3968 and CVE-2020-10648, the pattern across seven years of disclosures is the same: U-Boot's verified boot and memory-protection mechanisms work as designed when correctly configured and kept current, and every confirmed real-world bypass found a gap in that configuration or an unpatched version, not a break in the underlying cryptography.

On a firmware image a customer uploads, SoftWSP's pipeline extracts the component inventory (SBOM) — including the U-Boot version string and build configuration where the image exposes one — and matches it against known U-Boot CVEs such as the three above, flagging a version that predates the fix for CVE-2018-3968, CVE-2020-10648, CVE-2025-24857 or any other tracked U-Boot advisory. That automated SBOM-and-CVE-matching step, engineer-reviewed before it reaches a report, is genuinely useful for triage at scale: it tells you fast whether a specific firmware image ships a U-Boot build with a known, fixed vulnerability. It does not replace a manual review of that device's actual boot-chain configuration — whether `CONFIG_FIT_SIGNATURE` is enabled, whether the legacy image format is disabled, whether `bootdelay` and the environment's write permissions are hardened — because none of that is visible from a version number alone; a device can run a patched U-Boot release and still ship with verified boot turned off or autoboot wide open.