"Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely," Binarly writes — and the review turned up six flaws that could let attackers run code at the earliest stage of device startup.
Binarly's findings: six flaws in FIT signature verification
Firmware security company Binarly published a report this week disclosing six vulnerabilities in U-Boot's FIT (Flattened Image Tree) signature verification code. As Binarly summarizes, "This research revealed six distinct vulnerabilities, ranging in impact from denial of service (DoS) to arbitrary code execution during the verification of an untrusted image." The researcher team says two of the issues can lead to arbitrary code execution during firmware verification, while the remaining four can be exploited to crash devices.
The six BRLY identifiers and what each does
- BRLY-2026-037 — A flaw that can cause U-Boot to crash when processing a malicious firmware image and, under certain conditions, can be used for arbitrary code execution.
- BRLY-2026-038 — A memory corruption vulnerability that could allow attackers to execute arbitrary code during firmware signature verification.
- BRLY-2026-039 — An out-of-bounds read vulnerability that can crash devices by forcing U-Boot to read beyond the firmware image.
- BRLY-2026-040 — A null pointer dereference that allows specially crafted firmware images to crash the bootloader.
- BRLY-2026-041 — Improper validation of externally stored firmware data that can cause U-Boot to crash when processing malicious firmware images.
- BRLY-2026-042 — An unbounded recursion flaw that can exhaust available stack memory and crash the bootloader.
Binarly reports that most of the vulnerable code has existed since U-Boot version 2013.07, meaning the defects "potentially affect over 50 stable releases of the U-Boot project." The company also notes that, counting downstream vendor forks, the vulnerabilities have a broad industry impact.
Why flaws in U-Boot are especially consequential
U-Boot is one of the world's most widely used open-source bootloaders and is embedded in enterprise Baseboard Management Controllers (BMCs), networking gear, industrial systems, IoT devices, and other appliances. Because U-Boot is responsible for loading the operating system, weaknesses in the bootloader can let an attacker compromise a device before the operating system and its security software start.
The project includes a feature called Verified Boot, which uses cryptographic signatures to ensure that only firmware and operating system images signed by a trusted key are loaded during startup. The disclosed flaws sit in the code that validates those firmware images; if an attacker can exploit that verification process, they may be able to execute code "during the earliest stages of the boot process." That sequence — pre-operating-system execution — is the reason attackers could disable firmware protections, modify the boot process, or install persistent firmware malware that is difficult to detect or remove.
Exploitation avenues and stealth risks
Binarly emphasizes that exploiting these vulnerabilities does not always require physical access. On systems such as BMCs that support remote firmware updates, an attacker who has already compromised the management interface could upload a specially crafted firmware image to trigger the flaws. Because any successful arbitrary code execution would occur before the operating system loads, Binarly warns malicious activity would be hard to detect: it executes "before the operating system starts." Even defects that only crash U-Boot may render devices unavailable or blind operators to deeper compromise.
What this means for technologists and security teams, vendors, and end users
- Technologists and security teams: Track whether your devices use U-Boot's FIT verification code, prioritize systems with remote-update-capable BMCs, and prepare for firmware-level incident investigation — compromises at boot can evade OS-level detection.
- Hardware vendors and firmware maintainers: Binarly has reported the flaws and submitted patches; those patches "have since been accepted into the project's upstream codebase." Vendors must incorporate the upstream fixes into their own firmware updates before customers can receive them.
- End users and operators: Expect a lag between upstream patch acceptance and device-level availability; older or unsupported devices that no longer receive firmware updates "may never be patched," leaving some installed bases exposed.
Binarly's disclosure closes a research loop — the company found long-standing validation code problems, provided fixes, and saw those fixes land upstream — but it also opens a practical challenge: U-Boot is widely forked and bundled into vendor firmware, so the work of translating upstream patches into customer updates remains the decisive step. Whether vendors and operators can move those fixes into the field quickly will determine how many devices remain vulnerable to stealthy, pre-OS firmware attacks.
