Signed is not safe: what firmware signing and key management actually protect

A product page that says "secure boot enabled" does not settle whether a device is secure. Secure boot answers one narrow question: did this image come from whoever holds the signing key, unmodified? It has no opinion on whether the image is any good, whether the code checking it on the device works, or whether the signing key is sitting in a public repository. Three separate things have to go right for a fielded device to be secure, and signing owns exactly one of them. Yet it decides whether the other two can be fixed securely, since a fix can only reach fielded devices safely as a signed update.

The four CVEs covered here fall into three kinds of failure. Only one kind is a signing problem, and a signing vendor should say so plainly.

In short

• The signed code has a bug. Signing does not help. Patch it.

• The code that checks the signature is wrong. Signing does not help either. Keep the bootloader and update framework current.

• The signing key leaks or is a test key. This is the one signing and key management prevent.

1. The code is broken and the signature is perfect

CVE-2026-6687 is a stack overflow in FatFs, the filesystem library embedded in a vast range of microcontroller firmware. f_getlabel() reads the volume-label length from an exFAT disk and trusts it. The exFAT spec caps the label at 11 characters; the code never checks. An attacker who prepares a volume with an oversized label length can overflow the stack when the device reads it. The bug is rated CVSS 7.6 as a stack-based buffer overflow (CWE-121). Its attack vector is listed as physical, and that is where many readers stop worrying.

They should not. "Physical" here means an SD card, and plenty of people insert one over a device's life: the field technician with a diagnostics card, the customer restoring from backup, the refurbisher, someone on a forum sharing a "fixed" firmware image. runZero, which found the bug, reported no response from the maintainer during disclosure, so a fixed release should not be assumed for the version in use. The options are to carry the bounds check locally or build with FF_USE_LABEL 0 (CVE record).

Secure boot checked the signature, found it valid and booted the vulnerable code, exactly as designed. A signature tells you who built the image, not whether the code is safe.

2. The verifier is broken, which is worse

CVE-2026-46728 is a signature bypass in U-Boot, the bootloader under most embedded Linux. A signed FIT image packs the kernel, device tree and other parts under one signature, together with a list of which parts that signature covers. U-Boot did not include that list in what it hashed, so the list itself was unprotected. An attacker could swap in different parts and U-Boot still reported the image as verified. It is CWE-346, rated as high as CVSS 8.8, present since U-Boot 2013.07, and fixed in 2026.04 (CVE record).

Upgrading to 2026.04 is not the end of it. More bugs in the same FIT parser were disclosed on the U-Boot mailing list in May 2026, without CVE numbers, and fixed after 2026.04 shipped. The current release, U-Boot 2026.10, carries those fixes too (background).

The update path has the same weakness. CVE-2026-34155 is in RAUC, a widely used update framework for embedded Linux. In bundles using the older "plain" format with a payload larger than 2 GiB, an integer overflow meant the signature covered only the first few bytes of the payload. Take one legitimately signed bundle of that size, change the unsigned part, and the device installs it as genuine. It is rated CVSS 7.2 (CWE-347) and fixed in RAUC 1.15.2, which rejects such bundles. Bundles in the recommended "verity" and "crypt" formats were never affected (RAUC advisory). Here the signing step and the verify step both ran, and both were satisfied with a signature that protected almost nothing.

We dealt with this one ourselves. When the fix came out, we updated RAUC in the LAAVAT platform, so customers who sign RAUC bundles through LAAVAT were covered without touching their own pipelines.

This is the case that should worry teams most, because secure boot was not skipped. It ran and returned the wrong answer. A signature is only as trustworthy as the code that checks it. On these devices that code is the bootloader or the update framework. If it stays on an old version, it can accept a modified image however strong the signature is.

3. The key is public, and everything else is fine

PKfail (CVE-2024-8105) is the one that belongs to signing. In 2024, security researchers found that production UEFI devices across many OEMs had shipped with the test Platform Key from AMI's reference code. The certificate is named "DO NOT TRUST". The private key had been public since a 2022 leak. A UEFI Platform Key is a self-signed root with no authority above it, so nothing tells the firmware the key is bad. Anyone holding the leaked key could sign early-boot code and those machines would run it. Red Hat rates it 8.2 (CERT/CC, Red Hat).

PKfail is the headline version of something we see in smaller form. A signing key is generated on a developer's laptop during bring-up, because that is the quickest way to get the first image booting. The project ships, the key stays on the laptop, and nobody writes down where it is. Then the developer leaves the company. Either the key goes with the laptop and the fleet can no longer be updated, or it stays on a machine that nobody is responsible for. We have seen both.

This is the only failure in this post that a signing service can prevent. A key generated inside an HSM never exists as a file, so it cannot end up on a laptop or in reference code. Each signature is an approved and logged operation, and rotation and revocation are procedures the team has rehearsed.

Scorecard

Failure	Example	Does signing fix it?
Bug in signed code	FatFs, CVE-2026-6687	No. Patch it.
Verifier returns the wrong answer	U-Boot, CVE-2026-46728; RAUC, CVE-2026-34155	No. Update the bootloader or updater.
Key leaked or untrusted	PKfail, CVE-2024-8105	Yes. This is the job.

Signing owns one row of three, but it decides how the other two get fixed. A patch reaches a fielded device as a signed update, verified before install. Without controlled keys there is no safe way to ship the fix, and an attacker can use the same channel to ship something else. Signing does not find or repair the bug. It is what carries the repair to the device intact.

Do this today

• Keep an SBOM of every component in the firmware and check it against a vulnerability feed on a schedule, so a flaw in something like FatFs or U-Boot surfaces before a customer forwards the headline.

• Keep your components updated. A bootloader or library years behind upstream is the real exposure. For U-Boot that means 2026.10, which carries more security fixes than 2026.04; for RAUC, 1.15.2 or later with verity or crypt bundles. But the rule holds for every third-party component you ship.

• Verify the device's root of trust is a production key generated and held by you, never a default, sample, or test key from reference code. That is the mistake behind PKfail.

• Keep signing keys in an HSM, and treat signing as a managed process, not a file operation: authenticated and access-controlled, with an audit trail of who signed what and when, rotation and revocation, and no single person or single key as a point of failure. A private key that can be read out with cat is a file, not key management.

Where signing fits

Secure development keeps the code and the verifier sound. Signing and key management make sure every fix reaches the device intact. A device needs both, and each control covers only its own half.