Security Advisory

CVE-2026-46728: Das U-Boot FIT Image Signature Verification Bypass via Hashed-Nodes Omission

Last updated:
  • CVE-2026-46728

CVE-2026-46728 is a secure-boot bypass in Das U-Boot, one of the most widely used open-source bootloaders in embedded Linux and IoT devices: U-Boot verifies a signed FIT (Flat Image Tree) image by trusting a hashed-nodes property that lists which parts of the image the signature actually covers, but that property is itself unauthenticated and not included in the hash it describes, so an attacker who can modify the FIT, for instance with physical or local write access to boot media, can rewrite hashed-nodes to point the verifier at a decoy node while the device boots a different, unsigned image the attacker controls. NVD has analyzed the report and assigned a Primary CVSS v3.1 base score of 8.8 (high).

Vulnerability summary

8.8

High

0.2%

EPSS score (FIRST)

No

CISA KEV catalog

2026-05-16

Published

Vulnerability ID: CVE-2026-46728 · Source: NVD

Affected components

ComponentCPEVersion range
Das U-Boot (DENX Software Engineering) bootloader, FIT configuration signature verificationcpe:2.3:a:denx:u-boot:*:*:*:*:*:*:*:*2013.07 before 2026.04, plus the 2026.04-rc1, -rc2 and -rc3 release candidates (fixed in the final 2026.04 release)

What does this mean for affected devices?

CVE-2026-46728 affects Das U-Boot, the bootloader maintained by DENX Software Engineering that ships on a very large share of embedded Linux and IoT devices (routers, set-top boxes, industrial and automotive controllers) to load and verify the kernel and other boot images. NVD's description states plainly: "Das U-Boot before 2026.04 allows FIT (Flat Image Tree) signature verification bypass because hashed-nodes is omitted from a hash" (NVD).

NVD lists the CVE as "Analyzed" with a Primary CVSS v3.1 base score of 8.8 (high), vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H; the reporting CNA's own Secondary CVSS v3.1 score is 8.2 (high), vector CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H — both agree the flaw is high severity, differing mainly on whether low or high privileges are needed to reach the vulnerable code (NVD).

The fixing commit explains the root cause directly: "The hashed-nodes property in a FIT signature node lists which FDT paths are included in the signature hash. It is intended as a hint so should not be used for verification." Because the vulnerable verifier read that property as if it were authoritative rather than a hint, it could be tricked into checking the signature against one set of nodes while the device actually booted a different image. The fix "add[s] a function to build the node list from scratch by iterating the configuration's image references" instead of trusting the stored hashed-nodes list, and updates U-Boot's own test_vboot kernel test to confirm the attack is now caught at signature-verification time. The patch credits "Apple Security Engineering and Architecture (SEAR)" as the reporter (U-Boot commit 2092322b).

The same hashed-nodes design flaw was independently reported against the related barebox bootloader (tracked as CVE-2026-33243) and fixed in the same disclosure window; the joint advisory describes the shared defect as allowing attackers to "modify [hashed-nodes] and trick bootloaders into executing different images than those actually signed," and summarizes the fix as reconstructing "the hashed nodes list from the images used in a FIT configuration" rather than trusting the stored property (barebox Security Advisory GHSA-3fvj-q26p-j6h4).

This CVE is not listed in the CISA Known Exploited Vulnerabilities catalog as of catalog version 2026.11.06, and FIRST scores the probability of exploitation at 0.00212 (11.6th percentile) as of 2026-11-06, consistent with a flaw that requires local or physical access to boot media rather than being remotely reachable (CISA KEV, FIRST EPSS).

Device makers building secure-boot chains on U-Boot should update to 2026.04 or later; because this flaw defeats the signature check that secure boot depends on, any device whose threat model includes an attacker with local or physical access to flash/boot media, including supply-chain or lost/stolen-device scenarios, should treat the upgrade as a priority even without evidence of remote exploitation.

How to fix this class of issueNo SoftWSP guide covers this specific weakness class yet — the fix is usually the vendor patch or firmware update referenced above. Our related guide explains how to plan and verify it: NIST SP 800-40 Rev. 4: enterprise patch management planning, explained.

Evidence

  • Das U-Boot before 2026.04 allows FIT signature verification bypass because the hashed-nodes property is omitted from the signature hash it describes (CWE-346). — NVD
  • NVD status Analyzed; Primary CVSS v3.1 base score 8.8 (high), vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H; reporting CNA's Secondary CVSS v3.1 score 8.2 (high). — NVD
  • hashed-nodes is "intended as a hint so should not be used for verification"; fix reconstructs the node list from the configuration's own image references instead of trusting the stored property; reported by Apple Security Engineering and Architecture (SEAR); affects versions 2013.07 up to and including the 2026.04-rc1/-rc2/-rc3 release candidates, fixed in the final 2026.04 release. — U-Boot commit 2092322b
  • The same hashed-nodes defect was independently reported and fixed in the related barebox bootloader (CVE-2026-33243); joint advisory describes the shared root cause and fix approach. — barebox Security Advisory GHSA-3fvj-q26p-j6h4
  • Not present in the CISA KEV catalog as of catalog version 2026.11.06; EPSS score is 0.00212 (11.6th percentile) as of 2026-11-06. — FIRST EPSS

Related advisories

Sources

  1. NVD
  2. U-Boot commit 2092322b
  3. barebox Security Advisory GHSA-3fvj-q26p-j6h4
  4. CISA KEV
  5. FIRST EPSS

Frequently asked questions

What does an attacker need to exploit CVE-2026-46728?

The NVD Primary score's attack vector is local (CVSS:3.1/AV:L/...), meaning the attacker needs local or physical access to the boot media or FIT image that U-Boot will verify, such as supply-chain tampering or a lost or stolen device, rather than remote network access (per NVD).

Why does omitting hashed-nodes from the hash defeat signature verification?

hashed-nodes is a property in a FIT signature node that lists which FDT paths were included when the signature was computed, but the property itself was never covered by that signature; the fixing commit states it "is intended as a hint so should not be used for verification," yet the vulnerable code trusted it, letting an attacker redirect the verifier to check a decoy node while a different, unsigned image is what actually boots (per U-Boot commit 2092322b).

Does this flaw also affect other bootloaders besides U-Boot?

Yes. The same hashed-nodes design flaw was independently found and fixed in the related barebox bootloader, tracked as CVE-2026-33243, with a joint advisory describing the shared root cause and an equivalent fix of reconstructing the node list from the configuration's own image references (per barebox Security Advisory GHSA-3fvj-q26p-j6h4).

Which U-Boot versions are fixed, and is this being exploited in the wild?

Versions 2013.07 up to and including the 2026.04-rc1, -rc2 and -rc3 release candidates are affected; the final 2026.04 release fixes the issue. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, and FIRST's EPSS score of 0.00212 (11.6th percentile) reflects a low near-term exploitation probability, consistent with the local-access requirement (per CISA KEV; per FIRST EPSS).