- ByteRay researchers report that a crafted boot logo can overwrite memory in U-Boot and bypass secure boot (CVE-2026-71972).
- The image is decoded before the next boot stage is checked, and is often read from unsigned storage that attackers may be able to write to.
- A fix is in u-boot/next but not in a tagged release. Ask vendors about it and lock down logo storage.
The guard who opens the parcel before checking the ID
Secure boot works like a guard at a door. Each stage of startup must prove who it is before the next one runs. The guard is only useful if nothing gets past him unchecked.
CVE-2026-71972 describes a way to make the guard handle an unchecked parcel first. The parcel is a boot logo. The lesson is that a security check is only as strong as the least-trusted file it reads before it makes its decision.
What ByteRay found
Researchers Shahriyar Jalayeri and Mehrun P. Hunter of ByteRay Ltd published the advisory. It covers U-Boot, a widely used bootloader, which is the small program that starts a device and verifies what runs next.
During startup, U-Boot can decode a splash image, the logo shown on screen. The flaw sits in a function called video_display_rle8_bitmap(), in drivers/video/video_bmp.c. It handles BMP images compressed with RLE8.
RLE8 is run-length encoding. Instead of storing a hundred identical pixels, the file stores a count and a value. The decoder expands those runs into the framebuffer, the block of memory that holds what appears on screen.
How a logo becomes an attack
According to the advisory, the decoder does not check a run against the size of the framebuffer. A crafted image can therefore write past the end of it and into the neighbouring memory.
The researchers say the result is memory corruption and a crashed bootloader. They also say the decode happens before the next stage is authenticated. In their assessment, that lets the corruption reach the verification logic and bypass secure boot.
The attacker needs one thing: a way to place a crafted BMP in the storage that U-Boot reads the logo from. The advisory says that storage is commonly unsigned and attacker-writable.
The advisory does not say how many devices or vendors are affected. It does not report any exploitation in the wild. Treat it as a flaw to check for, not as a confirmed incident.
Why this matters beyond one function
Most security reviews ask whether the operating system is signed. Fewer ask what the bootloader reads before it starts checking signatures. A logo file feels like branding, so in our view it may rarely get threat-modelled.
This is the pattern worth taking away. Any input handled before a trust decision is part of the trust boundary, however harmless it looks. The risk falls on whoever owns the device, not the person who chose the logo format.
Ownership is also unclear. U-Boot is software that device makers embed. The fix sits upstream, but your organisation gets it only when the device vendor ships a firmware update.
The timeline matters. The fix was public in u-boot/next on July 29. The CVE record followed on September 29. Teams that track only CVE feeds would have had no identifier for that period. At the time of writing, the fix is not yet in a tagged release.
What to ask your team
Start with inventory. Which of your devices run U-Boot? Examples may include appliances, kiosks and embedded equipment. Ask each vendor whether its firmware includes the BMP RLE8 decode path and when a fixed build will ship.
Then ask where the boot logo is loaded from. If it comes from storage that is unsigned and writable, the advisory recommends restricting write access until the fix is deployed. That is a configuration change your team may be able to make today.
For teams that build their own firmware, the advisory points to a U-Boot build containing commit 5201e83342d64c2f438ea35158575f28225e752e. Ask whether your build pipeline tracks the u-boot/next branch, or waits for tagged releases.
Finally, ask a broader question. What else does the device read before it verifies anything? The answer is a list worth having before the next advisory arrives.
A lock is only as good as the first thing you let through the door.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: pop.byteray.co.uk.
