Auditing U-Boot Bootloader FIT Images for CVE-2026-46728: The Signature Flaw That Undermines Secure Boot on Embedded Linux

AIMeter

The disclosure meter stays where required; the useful part of this post is the boot-chain audit below. The real question is not whether a FIT image looks signed in a build log. The question is whether U-Boot will actually refuse to boot the wrong thing.

Why this U-Boot secure boot issue matters on embedded Linux

The public reporting around CVE-2026-46728 matters because U-Boot sits at the point where secure boot either holds or breaks. If the bootloader accepts a tampered FIT image, the rest of the chain is already too late.

That matters more on embedded Linux than on a desktop. On a typical board, U-Boot chooses the kernel, device tree, and initramfs that run first. If an attacker can swap any of those, they can change hardware policy, weaken isolation, or plant persistence before Linux userspace starts. That is why a bootloader verification bug is not “just a firmware issue.” It is a trust-chain failure.

My view is straightforward: if FIT signature verification can be bypassed on a deployed device, secure boot is not a security boundary. It is a build artifact with better branding.

What FIT images are supposed to protect

FIT, the Flattened Image Tree format used by U-Boot, bundles boot components into one signed artifact. In the intended design, the board boots one configuration, U-Boot verifies that configuration, and the configuration points to the exact kernel, device tree, and optional initramfs that were signed during release.

Kernel, device tree, and initramfs integrity

All three pieces matter:

• The kernel controls code execution.
• The device tree controls hardware description and boot-time policy.
• The initramfs controls the earliest userspace, where a lot of “temporary” security decisions happen.

If you only protect the kernel and ignore the device tree, you still leave room for trouble. A swapped DTB can change memory layout, disable peripherals, redirect console access, or alter how secure hardware is exposed. If the initramfs is untrusted, early-boot scripts can mount, rewrite, or leak data before the main OS even starts.

How U-Boot signature verification is supposed to enforce trust

The model is simple enough: the build pipeline signs the FIT, the board stores the public verification key, and U-Boot checks the signature before it jumps to the image. If the signature or hash does not match, boot should stop or fall back only to another equally trusted and authenticated path.

The details vary with the image layout, but the important rule is not subtle: trust has to be enforced at boot time, not just when the image is assembled.

A quick FIT audit usually starts with two questions:

• Which configuration is marked as default?
• Which blobs are actually covered by signatures?

If the config is signed but the payload is not, or if the payload is hashed but a different configuration can still be selected, the trust chain is weaker than it looks.

What the public CVE-2026-46728 reporting says, and what is still unconfirmed

Confirmed facts from the available source material

From the public reporting I could verify in the supplied material, these points are established:

I have not independently reproduced the CVE from source material this thin, so I would not pretend the mechanism is settled.

Likely failure modes worth testing in your own firmware

Even without the full advisory, a few failure patterns are worth checking right away:

• a signed configuration that points to an unsigned blob
• a signed FIT that still boots if the default config is changed
• a hash check that passes while the signature check is skipped
• a recovery or fallback path that loads a different image class entirely
• an environment-variable override that selects an unverified boot source
• rollback to an older signed image that is still trusted but no longer safe

My guess, and this is only an inference, is that the real exposure will be a trust-confusion problem rather than a broken RSA primitive. In practice, boot-chain bugs usually come from “this path was supposed to be impossible” logic.

How to audit a firmware pipeline for FIT verification gaps

Inspect the FIT description and signature policy with mkimage

Start with the artifact itself. You want to know what was signed, what was hashed, and what the bootloader is expected to enforce.

Useful commands:

dumpimage -l firmware.itb
dtc -I dtb -O dts firmware.itb | sed -n '/signature/,+25p'

If you still have the source FIT description, inspect the .its file too. The key question is not just whether a signature node exists. The real question is whether that signature covers the full boot configuration you care about.

A healthy layout should make it obvious which config is authoritative. If the image has multiple configurations and only one is signed, that is a place where operator error or a buggy fallback can become a bypass.

A build-time signing step often looks like this:

mkimage -f firmware.its -k keys/ -K u-boot.dtb -r firmware.itb

That command is not a defense by itself. It only helps if the resulting artifact is the one U-Boot actually verifies on-device.

What I look for in the FIT structure:

• a clear default configuration
• signature nodes tied to the configuration, not just individual blobs
• coverage for kernel, device tree, and initramfs where applicable
• no unsigned “alternate” configuration that can be selected at runtime

Reproduce a boot attempt and capture U-Boot verification output

For a lab board, I would check the boot path directly from the U-Boot console.

printenv bootcmd boot_targets
printenv | grep -E 'verify|bootargs|bootcount|altbootcmd'
bootm ${fitaddr}#conf-1

Then test a tampered lab copy, not a production image. A simple integrity check is to change one byte in a copied FIT and see whether the bootloader refuses it.

cp firmware.itb firmware-tampered.itb
printf '\x00' | dd of=firmware-tampered.itb bs=1 seek=4096 conv=notrunc
dumpimage -l firmware-tampered.itb

What matters is the behavior, not the exact byte offset. If the tampered image still boots, the problem is not theoretical.

The result you want is a hard failure at the bootloader boundary. A bad result is any of the following:

• the boot succeeds anyway
• U-Boot prints a warning but continues
• U-Boot silently falls back to another source
• a recovery path loads the same unverified payload under a different name

Check whether alternate boot paths bypass the verified configuration

This is where a lot of “secure boot” stories get weak in real fleets.

Boards often keep a recovery path for good reasons: removable media, network boot, a second partition, or an altbootcmd fallback for bricked devices. The mistake is leaving those paths unauthenticated while assuming the main FIT verification covers everything.

Audit every place the board can boot from:

• bootcmd
• boot_targets
• recovery partitions
• USB or SD fallback
• network boot
• extlinux-style configs
• any vendor-specific rescue mode

If one of those paths can load a kernel or initramfs without the same verification policy, that path is part of the attack surface.

Failure patterns that would undermine the trust chain

Signature coverage that misses the real payload

This is the classic mistake: the image looks signed, but the wrong thing is protected.

Examples:

• kernel signed, DTB unsigned
• kernel and DTB signed, initramfs omitted
• config signed, but the config can reference alternate blobs
• hash verification enabled, but signature enforcement not required

If the device tree can be swapped, the device may still boot while running with altered hardware assumptions. That is enough to change the security story.

Configuration confusion between signed and unsigned components

FIT makes it easy to create multiple valid-looking boot configurations. That is useful operationally and dangerous when policy is sloppy.

A common failure mode is this:

1. the release pipeline signs one configuration
2. the board also accepts another configuration
3. the boot script or recovery logic can pick the weaker one

If you have both signed and unsigned variants in the same artifact family, you need to be brutally explicit about which one is allowed on production hardware.

Rollback, fallback, and environment-variable abuse

A secure boot chain can still fail if rollback is not controlled.

If an attacker can force:

• an older but still valid signed image
• a fallback partition with weaker contents
• an environment-variable change that points at a different boot source

then signature verification alone is not enough. I would treat writable bootloader environment storage as part of the trust boundary, not as a harmless convenience feature.

Defensive checks that hold up in practice

Require verification at the bootloader boundary, not just in update tooling

This is the first thing I would fix if I inherited a fleet.

Update-time checks are useful, but they are not the trust boundary. The only check that really matters is the one U-Boot performs immediately before launching the kernel.

If the bootloader can be coerced into loading unsigned or differently signed content, then your updater may be perfect and your device may still be compromised.

Protect signing keys, build inputs, and release artifacts

The signing system is only as strong as the place that produces the signature.

Practical controls I would want:

• offline or hardware-backed signing keys
• a locked-down signing step in CI/CD
• strict control over .its source files and build inputs
• artifact provenance for the shipped FIT image
• separation between build servers and release-signing systems

A compromised build pipeline can still produce correctly signed malware. Secure boot will faithfully protect the attacker’s image if the attacker controls signing.

Add negative tests in CI for tampered FIT images

This is the cheapest high-value check.

Your release pipeline should include tests that:

• flip one byte in the kernel blob
• remove a signature node
• swap the default configuration
• point the bootloader at an unsigned recovery image
• try a known-bad fallback path

A good test fails closed and records the exact U-Boot refusal. A weak test only proves that a happy-path image boots.

What I would fix first in a real embedded fleet

I would fix the bootloader policy first, then the release process, then the recovery story.

Why that order?

Because if the device can still boot the wrong thing, every higher-layer control is secondary. A perfect signing ceremony does not matter if a fallback path ignores it. A hardened update server does not matter if a board will boot from an unsigned USB stick.

So my priority list would be:

1. make U-Boot reject untrusted FIT content at boot time
2. remove or authenticate any alternate boot path
3. protect bootloader environment variables and rollback controls
4. add tamper tests to CI and to device acceptance testing
5. verify that production boards actually run the expected boot policy, not just the intended one

Conclusion

The public reporting on CVE-2026-46728 points to a real class of risk: if FIT signature verification fails open, embedded Linux secure boot is only pretending to be secure. I have not independently confirmed the exact flaw from the thin source material available here, so I would keep the wording precise. But I would not be relaxed about it.

My practical take is this: do not audit FIT images by looking for a signature field and moving on. Audit the boot paths, the fallback logic, the environment, and the exact moment U-Boot decides to trust the payload. That is where the bug lives when this class of issue turns into a real fleet compromise.

Further Reading

• U-Boot FIT images documentation
• U-Boot verified boot documentation
• U-Boot mkimage documentation