Secure boot rests on a simple promise: before the device runs a firmware image, it checks that the image is signed by someone it trusts. Binarly Research has published six vulnerabilities in the code that performs that check in U-Boot, and two of them allow code execution during the check itself.
That is a specific and awkward category of failure. The verification step is not being bypassed. It is being used as the entry point.
The six
Binarly tracks them under its own advisory identifiers:
| ID | Class | Effect |
|---|---|---|
| BRLY-2026-037 | Crash, potentially code execution | Denial of service; arbitrary execution under some conditions |
| BRLY-2026-038 | Memory corruption | Arbitrary code execution during verification |
| BRLY-2026-039 | Out-of-bounds read | Device crash from a malformed image |
| BRLY-2026-040 | Null pointer dereference | Bootloader crash from a crafted image |
| BRLY-2026-041 | Improper validation | Crash when processing a malicious image |
| BRLY-2026-042 | Unbounded recursion | Stack exhaustion, crash |
All six are in the FIT (Flattened Image Tree) signature verification path. FIT is the container format U-Boot uses to bundle a kernel, device tree and other components, together with the signatures that prove they are authentic.
Four of the six produce crashes. That matters less on a phone than on an embedded device that is expected to boot unattended in a location nobody visits — a crash at boot on a remote system is an outage requiring physical access.
The two that allow code execution are the serious ones, and they run before the operating system loads, which means before any of the security machinery people usually rely on exists.
Why "since 2013.07" is the number that hurts
The vulnerable code dates to U-Boot 2013.07. More than fifty stable releases have shipped since.
Take a moment with the implication. Any device whose firmware was built on U-Boot in the last twelve years is a candidate. Not because vendors were careless, but because they used the standard bootloader and inherited its verification code, as intended.
U-Boot runs in places most people never think about as computers:
- Baseboard management controllers in enterprise servers — the out-of-band management processor that has power over the host and its own network interface
- Networking equipment — routers, switches, gateways
- Industrial systems
- IoT devices generally
The BMC case is worth isolating. A BMC exists to manage a server independently of its operating system. It can power-cycle the machine, mount virtual media and access the console. Code execution in a BMC's bootloader is control of the server underneath, below anything the server's OS can see or defend.
What an attacker needs
This is where the honest framing matters, because "flaws in secure boot" invites more alarm than the situation warrants for most readers.
To exploit these, an attacker must get a crafted firmware image in front of the verification routine. Reaching that point generally means one of:
- an update mechanism that fetches images over a channel you can influence
- physical or local access to write to the boot medium
- an existing foothold with enough privilege to stage an image for the next boot
So this is not remote, unauthenticated compromise of every device running U-Boot. It is a privilege-escalation and persistence capability — the step that turns access you already have into something that survives reinstallation and sits below the operating system.
That is precisely what makes it valuable to anyone who has already got in. Firmware persistence outlives disk wipes and OS reinstalls, and it is invisible to endpoint tooling that starts after the boot process.
Binarly's stated concern reflects this: attackers could disable firmware security features, modify the boot process, and install persistent firmware malware.
The patching problem is the real story
Patches have been accepted into U-Boot's upstream codebase. If you build your own firmware, the fix is available.
Almost nobody reading this builds their own firmware.
The chain from an upstream U-Boot fix to a device in service runs: upstream commit → silicon vendor's board support package → device manufacturer's firmware build → release, testing and distribution → an administrator or owner applying it. Each link is a company with its own priorities and its own product lifecycle.
For a device still under active support, that chain works, slowly. For a router bought four years ago, a controller in a factory, or a server generation the vendor has moved past, the chain is broken at some link and the fix will never arrive.
Binarly's own note is blunt about it: older, unsupported devices may never receive patches.
This is the structural condition of embedded security. The vulnerability is fixed and the population is not, and the gap between those two facts is measured in device lifetimes — which for industrial and networking hardware is a decade or more.
What to actually do
- Ask vendors specifically about FIT verification. "Are you affected by the Binarly U-Boot advisories?" is answerable. "Is your firmware secure?" is not. Get the advisory IDs into the ticket.
- Inventory what runs U-Boot, starting with BMCs. Most organisations cannot answer this, which is why it is worth doing before it is urgent.
- Isolate management interfaces. BMCs on a routable network are the highest-value instance of this. They should be on a management network reachable from a small set of hosts, which is good practice independent of this advisory.
- Control the update path. Since exploitation requires getting an image in front of the verifier, the integrity of how images reach devices is the practical control — signed transport, restricted write access to boot media, no unauthenticated update endpoints.
- Treat end-of-support hardware as a decision, not a state. If a device will never receive this fix, the choice is to accept the risk explicitly or to replace it. Drifting is the option most organisations take by default, without deciding.
The pattern worth noticing
This lands in the same week as an eighteen-year-old use-after-free in the Linux kernel's SCTP code, found by an AI research pipeline. Both are old code in widely deployed infrastructure, both sat unexamined for over a decade, and both were found by researchers deliberately going looking rather than by an incident.
The unglamorous conclusion is that the security-critical parts of foundational open-source infrastructure have received far less scrutiny than their deployment footprint would justify — and the backlog is being worked through now, by people with better tools, faster than the ecosystem can ship the fixes.
