Researchers at firmware security firm Binarly have found six new flaws in U-Boot, the small program that starts up hardware ranging from home routers and smart cameras to management chips inside data-center servers. Four of the vulnerabilities can crash a device, while the other two could allow an attacker who supplies a malicious image to execute code before the bootloader has confirmed that the software is genuine.
Key Highlights
Binarly reported six U-Boot flaws tracked as BRLY-2026-037 through BRLY-2026-042.
All six vulnerabilities can be triggered while U-Boot processes an untrusted FIT image, before signature verification is complete.
Four issues can cause denial of service, while two memory-corruption flaws may allow arbitrary code execution during the boot process.
Most of the affected code has been present since U-Boot v2013.07 and across more than 50 stable releases.
Upstream fixes were merged in June, but no CVE identifiers had been assigned at the time of reporting.
What U-Boot Does
U-Boot is an open-source bootloader that runs before the operating system. It initializes hardware, loads the next stage of software, and, on secured devices, verifies that the software matches signed and trusted images.
Because U-Boot sits near the root of the boot chain, vulnerabilities at this stage can affect everything that loads afterward, including kernels, init systems, and security tools that depend on the platform starting from a trusted state.
The Binarly research focused on U-Boot's Verified Boot mechanism, specifically the processing and verification of FIT (Flattened Image Tree) images. FIT packages can contain components such as a kernel, device tree, ramdisk, and other boot artifacts that U-Boot processes before handing control to the operating system.
For broader context on how firmware vulnerabilities can affect consumer hardware, see our coverage of an important firmware update for Nintendo Switch owners.
Why Parsing Bugs Before Signature Checks Are Dangerous
All six vulnerabilities can be reached while U-Boot is still processing an untrusted image, before the image's signature has been fully verified. That timing is important because security mechanisms cannot protect against a parser vulnerability that is reached before verification is complete.
A crash could leave a device unable to boot or cause repeated reboots. More serious memory-corruption vulnerabilities may allow code execution during the boot process, potentially placing attacker-controlled code below the operating system and outside the visibility of many conventional security tools.
Binarly reported that most of the vulnerable code has existed since U-Boot v2013.07 and appears across more than 50 stable releases. The same code is also used in vendor firmware built on top of U-Boot.
The affected ecosystem includes consumer networking equipment and server-management hardware, making the issue relevant to embedded-device and firmware supply-chain security.
The Six Flaws
The vulnerabilities are tracked in Binarly advisories BRLY-2026-037 through BRLY-2026-042. No CVE identifiers had been assigned at the time of reporting. The six issues fall into two broad groups: two memory-corruption vulnerabilities that may enable code execution and four vulnerabilities that can cause crashes or denial of service.
BRLY-2026-037 and BRLY-2026-038 share a root cause involving U-Boot's use of fdt_get_name, a lookup function in the device-tree parsing library used by multiple projects. With a malformed image, the function can return a null pointer and a negative length, and the affected U-Boot code does not properly validate those values.
In one case, the null pointer can reach a memory-copy operation that may become a stack buffer overflow on systems where address zero is mapped. In the other, a negative length can be used in pointer arithmetic that moves backward in memory and may overwrite a saved return address. Depending on the memory layout and execution conditions, either vulnerability could potentially result in attacker-controlled code execution.
BRLY-2026-039 and BRLY-2026-041 can cause U-Boot to read beyond the end of an image because attacker-controlled size or offset values are not handled safely.
BRLY-2026-040 involves a null-pointer dereference when U-Boot processes an older image format without properly validating the returned pointer.
BRLY-2026-042 can exhaust the stack when a deeply nested image causes an early validation routine to recurse repeatedly until available stack memory is exhausted.
Binarly published proof-of-concept images and reproduction steps for the vulnerabilities and demonstrated them against standard U-Boot builds. There were no reports of these vulnerabilities being exploited in real-world attacks at the time of publication.
Who May Be Affected
Products that use U-Boot to verify FIT images before boot may be exposed if they contain vulnerable code and allow an attacker to influence the boot image.
Binarly specifically discussed affected categories including home routers, smart cameras, and data-center server-management hardware. These environments can be difficult to update because bootloader fixes generally have to be integrated into vendor firmware rather than installed directly by end users.
Actual exposure depends on several factors, including whether a vendor's firmware contains the vulnerable U-Boot code and whether an attacker can place or supply a malicious image through an available update or boot path.
That delivery requirement can significantly affect practical exploitability. However, it does not necessarily mean physical access is always required. In some embedded and server-management environments, remote management or firmware-update mechanisms can provide a path to deliver malicious firmware if those mechanisms are themselves compromised or insufficiently protected.
For another example of a serious device security issue and how a vulnerability can affect users, see our coverage of a security flaw in the Google Pixel modem.
Severity: Crash Versus Code Execution
The six vulnerabilities do not have identical consequences.
A denial-of-service condition can crash the bootloader and potentially leave a device unable to start correctly. Depending on the hardware and recovery mechanism, restoring a device could require reflashing its firmware or physical access to the equipment.
The two memory-corruption vulnerabilities are potentially more serious because successful exploitation could provide code execution during the boot process. Code running at this stage would execute before the operating system and many of its security controls are active.
Boot-time compromise can therefore affect the integrity of the software chain that follows. However, exploitation still depends on the specific device, memory layout, available attack path, and the ability to supply a malicious image.
Remediation and Release Timing
At the time of reporting, there was no stable U-Boot release containing all six fixes. Binarly advised vendors and maintainers to apply the upstream fixes referenced in the individual advisories and track the vulnerabilities using their BRLY identifiers because CVE identifiers were not yet available.
U-Boot merged the six patches in June, but the July v2026.07 release had already entered its freeze period in April and shipped without the fixes. The next planned release, v2026.10, was scheduled for October.
This creates a gap between upstream remediation and the availability of a stable release. Embedded-device manufacturers may take additional time to integrate, test, and ship those fixes in their own firmware.
For consumers and IT teams, the practical response is therefore to monitor firmware and security advisories from individual device manufacturers rather than expecting a single universal U-Boot update.
Related Boot-Security Context
These vulnerabilities are part of a broader pattern of security problems involving software that processes data early in the boot chain.
CVE-2026-33243, patched in April, affected related signature logic in U-Boot. A separate issue in the barebox bootloader involved similar image-processing components.
The use of fdt_get_name is also notable because it comes from libfdt, the flattened-device-tree library shared with the Linux kernel and other boot-related software. An unchecked return value can therefore create security problems wherever similar parsing assumptions are made.
Binarly also compared the situation with LogoFAIL, a collection of image-parsing vulnerabilities in PC firmware that demonstrated why parsers operating early in the boot process can remain attractive targets for security researchers.
Conclusion
The six U-Boot vulnerabilities demonstrate why verified boot depends not only on cryptographic signature checks but also on the security of the code that processes an image before verification is complete.
Four of the reported flaws can cause denial of service, while two memory-corruption vulnerabilities may allow code execution under certain conditions. The long history of some affected code and U-Boot's use across embedded and infrastructure products increase the number of potentially affected systems.
Upstream fixes have been merged, but the practical security impact will depend on how quickly device manufacturers integrate those changes into shipping firmware.
Organizations managing routers, cameras, server-management controllers, and other U-Boot-based systems should identify affected products, monitor vendor firmware advisories, and treat bootloader integrity as part of their broader firmware and supply-chain security strategy.
Originally reported by The Hacker News.
