13-Year-Old U-Boot Flaws Enable Pre-OS Attacks on Embedded Devices

Six vulnerabilities lurking in U-Boot's bootloader code for over a decade could let attackers execute malicious code before the operating system even loads—a worst-case scenario for firmware security that affects everything from data center servers to home routers.

Firmware security firm Binarly disclosed the flaws this week, tracked as BRLY-2026-037 through BRLY-2026-042. Two enable arbitrary code execution during the boot process. Four cause denial-of-service conditions that can brick devices. All six stem from improper handling of untrusted firmware images before signature validation completes.

What Makes This So Dangerous

U-Boot is the de facto bootloader for embedded Linux systems. It initializes hardware, loads the kernel, and—when properly configured—verifies that firmware hasn't been tampered with. That verification relies on FIT (Flattened Image Tree) signatures, a cryptographic check meant to establish a hardware root of trust.

The problem: U-Boot processes attacker-controlled data in the FIT image before completing signature verification. If a crafted image triggers one of these bugs, the signature check never matters.

"Counting many downstream vendor forks, these vulnerabilities have a significant impact on the industry," Binarly noted in its advisory.

Technical Breakdown

The flaws cluster into two categories:

Code Execution (High Severity)

• BRLY-2026-037 and BRLY-2026-038: Both trace to unchecked return values from fdt_get_name, a function in the device-tree parsing library. When processing a malformed image, the function can return a null pointer with a negative length. U-Boot uses both values without validation, leading to memory corruption and potential arbitrary code execution.

Denial of Service (Medium Severity)

• BRLY-2026-039 and BRLY-2026-041: Out-of-bounds reads caused by trusting attacker-controlled size and offset values in firmware images.
• BRLY-2026-040: Null pointer dereference when handling legacy image formats without proper checks.
• BRLY-2026-042: Unbounded recursion that exhausts stack memory when validating deeply nested image structures.

Affected Scope

The vulnerable code paths have existed since U-Boot version 2013.07, meaning more than 50 stable releases are potentially affected. Devices at risk include:

• Enterprise Baseboard Management Controllers (BMCs)
• Networking equipment
• Industrial control systems
• IoT devices and smart appliances
• Any embedded Linux system using U-Boot's verified boot

The supply chain implications are substantial. Vendors routinely fork U-Boot and ship their own customized builds. Many of those forks haven't been updated in years. Others ship on devices with no firmware update mechanism at all. Like the malicious payment SDKs recently found on npm and PyPI, this is another reminder that trusted components in the software supply chain can harbor hidden risks for extended periods.

Attack Vectors

On systems supporting remote firmware updates—BMCs in particular—an attacker with access to the management interface could upload a specially crafted firmware image. The malicious image would trigger the vulnerability during the boot verification step, potentially installing persistent firmware malware that survives OS reinstallation.

This mirrors the challenge security teams faced with long-lived kernel flaws like Januscape, where the bug existed for years before discovery and downstream patching took additional months.

For devices requiring physical access to update firmware, exploitation is more limited but still viable in scenarios involving supply chain compromise or insider threats.

Patch Status

Binarly coordinated disclosure with U-Boot maintainers, and patches for all six vulnerabilities have been merged into the upstream repository. Here's the catch: U-Boot's July 2026 release (v2026.07) entered feature freeze in April and shipped without the fixes. The October release (v2026.10) will include them.

That timeline means vendors are on their own for the next few months. Organizations running affected devices should:

1. Inventory U-Boot deployments across BMCs, network equipment, and embedded systems
2. Check vendor advisories for firmware updates addressing these specific flaws
3. Restrict management interface access to limit attack surface on BMCs
4. Monitor for unusual firmware update activity that could indicate exploitation attempts

For devices that never receive vendor updates—and there will be many—the only mitigation is network segmentation and strict access controls.

Why This Matters

Pre-boot attacks represent the nightmare scenario for defenders. Malware executing before the OS loads can disable security features, modify the boot chain, and persist invisibly below the operating system's detection capabilities. Traditional endpoint protection tools have no visibility into firmware-level threats.

The 13-year window between introduction and discovery underscores a persistent problem in embedded security: bootloader code gets less scrutiny than operating systems despite being equally critical. Organizations relying on U-Boot's verified boot feature assumed they had a root of trust. For over a decade, that trust was misplaced.

If you're managing infrastructure that includes BMCs or embedded Linux devices, this is worth escalating. Check our security resources for guidance on firmware security practices, and follow hacking news for updates as vendors respond.