New U-Boot flaws could enable stealthy firmware attacks

Six vulnerabilities in the widely used U-Boot bootloader have been discovered that could allow attackers to execute malicious code during device boot, potentially enabling stealthy firmware attacks that compromise security protections and install persistent malware.

U-Boot is one of the world's most widely used open-source bootloaders and is found in many embedded Linux devices, including enterprise servers' Baseboard Management Controllers (BMCs), networking equipment, industrial systems, IoT devices, and other appliances.

Because U-Boot is responsible for loading the operating system, vulnerabilities in the bootloader can allow attackers to compromise a device before the operating system and its security software have a chance to start.

One of its security features, known as Verified Boot, uses cryptographic signatures to ensure that only firmware and operating system images signed by a trusted key are loaded during startup.

In a report published this week, firmware security company Binarly disclosed six vulnerabilities in U-Boot's FIT (Flattened Image Tree) signature verification code.

"Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely," explains Binarly.

"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."

According to the researchers, two of the flaws can potentially lead to arbitrary code execution during firmware verification, while the remaining four can be exploited to crash vulnerable devices. 

As these flaw impact the code for validating firmware images before the operating system starts, if an attacker can exploit that process, they may be able to execute malicious code before the operating system loads.

The six disclosed vulnerabilities are:

• 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.

According to Binarly, most of the vulnerable code has existed since U-Boot version 2013.07, causing the flaws to potentially affect more than 50 releases of the project as well as vendors who utilized the vulnerable code in their own firmware.

"This means that they potentially affect over 50 stable releases of the U-Boot project. Counting many downstream vendor forks, these vulnerabilities have a significant impact on the industry," explains Binarly.

If successfully exploited, the arbitrary code execution vulnerabilities could allow attackers to execute code during the earliest stages of the boot process.

Because this occurs before the operating system loads, attackers could potentially disable firmware security features, modify the boot process, install persistent firmware malware, or carry out other malicious actions with high levels of access.

Binarly says that malicious would be difficult to detect because they execute before the operating system starts.

Binarly says 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 exploit the flaws.

Binarly reported the vulnerabilities to the U-Boot maintainers and submitted patches for all six issues, which have since been accepted into the project's upstream codebase.

However, because U-Boot is integrated into firmware by individual hardware manufacturers, the fixes must first be incorporated into vendors' firmware updates before they can be distributed to customers.

Older or unsupported devices that no longer receive firmware updates may never be patched.