Security researchers have identified six vulnerabilities in the widely deployed U-Boot bootloader that could allow attackers to execute malicious code during the earliest stages of a device's startup process. If successfully exploited, the flaws could enable firmware-level attacks capable of bypassing security protections before the operating system loads and establishing malware designed to remain on affected systems.
As one of the most widely used open-source bootloaders, U-Boot plays a fundamental role in the startup sequence of embedded Linux devices by initializing hardware and loading the operating system. It is integrated into a broad range of technologies, including enterprise server Baseboard Management Controllers (BMCs), networking equipment, industrial control systems, Internet of Things (IoT) devices, and numerous other embedded appliances.
Because the bootloader executes before the operating system and endpoint security tools become active, vulnerabilities at this stage can have far-reaching consequences. An attacker who gains control during the boot process may be able to interfere with the system's trusted startup sequence before conventional security controls have an opportunity to detect or prevent malicious activity.
One of U-Boot's primary security mechanisms is Verified Boot, which uses cryptographic signatures to verify the authenticity of firmware and operating system images before they are executed. During startup, only images signed with a trusted cryptographic key are intended to be loaded, helping prevent unauthorized or modified firmware from running on the device.
In a technical report published this week, firmware security company Binarly disclosed six vulnerabilities affecting U-Boot's Flattened Image Tree (FIT) signature verification code. The FIT framework is responsible for validating firmware images during the boot process, making it a critical component of the platform's chain of trust.
According to Binarly, researchers examined the verification logic because of its importance in maintaining firmware integrity during startup. Their analysis uncovered six distinct vulnerabilities ranging from denial-of-service conditions that can interrupt the boot process to flaws capable of enabling arbitrary code execution while processing untrusted firmware images.
The researchers said two of the vulnerabilities could potentially allow arbitrary code execution during firmware verification, while the remaining four can be exploited to trigger crashes during the boot process. Since these weaknesses affect the validation of firmware before the operating system starts, a successful exploit could allow malicious instructions to execute before higher-level security mechanisms become operational.
The disclosed vulnerabilities include a flaw identified as BRLY-2026-037 that can cause U-Boot to crash when processing a specially crafted firmware image and, under certain conditions, may also permit arbitrary code execution. BRLY-2026-038 is a memory corruption vulnerability that could enable attackers to execute malicious code during firmware signature verification. BRLY-2026-039 involves an out-of-bounds read that may force U-Boot to access memory beyond the firmware image, resulting in a system crash. BRLY-2026-040 is a null pointer dereference vulnerability that allows crafted firmware images to terminate the bootloader unexpectedly. BRLY-2026-041 stems from insufficient validation of externally stored firmware data and can also be used to crash vulnerable systems. The sixth flaw, BRLY-2026-042, involves unbounded recursion that can exhaust available stack memory and prevent the bootloader from completing the startup process.
Binarly noted that much of the affected code has been present since U-Boot version 2013.07, meaning the vulnerabilities could impact more than 50 stable releases of the project. Because many hardware manufacturers maintain customized downstream versions of U-Boot within their own firmware, the potential exposure extends beyond the upstream project to a large number of commercial products deployed across multiple industries.
If the arbitrary code execution vulnerabilities are successfully exploited, attackers could gain execution during one of the earliest phases of system initialization. Operating at this level may allow threat actors to alter the boot sequence, disable firmware security mechanisms, deploy persistent firmware malware, or perform other privileged actions before the operating system begins loading.
Firmware-based attacks can also be considerably more difficult to identify than malware operating within the operating system. Since malicious activity occurs before the operating system initializes, traditional endpoint security software and many monitoring tools may have limited visibility into the compromise, allowing malicious modifications to remain undetected for extended periods.
Binarly also noted that exploitation does not necessarily require physical access to a device. Systems equipped with Baseboard Management Controllers that support remote firmware updates could become vulnerable if an attacker first compromises the management interface. In such cases, a specially crafted firmware image could be uploaded and processed during the update process, potentially triggering the identified vulnerabilities.
The researchers reported all six vulnerabilities to the U-Boot maintainers and submitted patches addressing each issue. Those fixes have since been accepted into the project's upstream codebase. However, because U-Boot is incorporated into firmware by individual hardware manufacturers, vendors must integrate the patches into their own firmware releases before updates become available to customers.
Organizations operating embedded systems should monitor firmware advisories issued by their hardware vendors and apply security updates as they become available. Restricting access to firmware management interfaces, securing remote administration services such as BMCs, and verifying firmware authenticity before deployment can further reduce exposure while patches are being distributed.
Devices that have reached end-of-life or no longer receive firmware updates may remain permanently vulnerable, underscoring the long-term security challenges posed by legacy embedded systems that continue operating long after vendor support has ended.
