The signature was valid and the boot was still owned

On June 9, 2026, two Secure Boot vulnerabilities landed in the NVD on the same day. Neither involves broken cryptography. Signature verification did its job in both cases, and attacker-controlled code still ran before the OS.

If your Secure Boot threat model is "someone breaks the math," you are guarding a layer attackers have mostly stopped bothering with. The failures live in the enforcement logic around the signatures.

Two CVEs, two failure classes

CVE-2026-45588 is a Windows Secure Boot bypass, CWE-693, protection mechanism failure. The check exists, the trust decision gets made, and nothing downstream enforces it. An attacker with admin stages modified boot components or manipulates Secure Boot policy, reboots, and gets persistence that survives a full OS reinstall. The footprint is wide: Windows 10 1607 through 22H2, Windows 11 23H2 through 26H1, Server 2012 through 2025. No public exploit, not in CISA KEV at publication.

CVE-2026-8863 hits multiple Microsoft-signed UEFI shims. Their signatures are fine. The validation logic inside the shim is broken, so it loads unsigned code, and firmware keeps trusting the shim until the DBX revocation list is updated. Windows boxes and every Linux distro using Microsoft-signed shim are affected. Fixing one machine means the Microsoft update, the DBX update actually landing on that machine, and moving Linux systems to a non-revoked shim build.

A signature answers "who shipped this binary." It says nothing about whether the binary enforces policy. (A UK outlet is also reporting a UEFI Secure Boot bypass on a claimed 200,000 Framework laptops. Same class, OEM firmware this time. Treat the number as a headline claim until the reporting holds.)

Five ways boot chains fail without touching a cipher

1. Protection mechanism failures. The check exists on paper, enforcement never fires.
2. Signed-but-dangerous tooling. Valid signature, broken validation or excessive capability inside.
3. Rollback gaps. Revocation that exists on a server but not on the device is no revocation. The embedded analog: an anti-rollback counter in silicon that was never wired into the boot decision.
4. Attestation blind spots. Measured boot catches what the policy measures. Everything else attests cleanly, forever.
5. Debug and fuse misconfiguration. Production units with debug enabled, secure-boot fuses never blown, keys left in a test state.

"But these bugs need admin." True, and irrelevant. Admin is the staging cost. The payout is persistence that survives reimaging, which turns your incident response from "reimage and move on" into firmware-level remediation.

What I'd audit first

For the shim CVE specifically: hash-compare shimx64.efi, shimia32.efi, and shimaa64.efi against vendor baselines, confirm the latest DBX update is present per machine, cross-check shim version with mokutil --sb-state or bcdedit /enum firmware, and forward TPM PCR 0-7 measurements for drift analysis.

Embedded folks, the classes are stack-independent. Microsoft's Azure attestation measurement list (db and dbx digests, KEK and PK signatures, Secure Boot state, debugging disabled on production machines, code integrity policy) is an embedded audit checklist wearing cloud clothes. Their failure path is worth copying: a misconfigured host arrives, the TCGLog carries indicators, attestation fails, the host is blocked until post-mortem. The caveat cuts the other way too. If your policy never checks debug state, a factory-misconfigured machine attests cleanly forever.

Takeaways you can use this week:

• Treat DBX as per-device state. Verify the update landed on each machine, not that you deployed it to a server.
• Pull production units from inventory (not dev boards) and try the debug port yourself. Then verify the secure-boot fuse is actually blown.
• Borrow the 45588 indicator list for mixed fleets: unexpected db/dbx/KEK/PK changes, unsigned BCD entries, bootmgfw.efi or winload.efi modified outside Windows Update, new ESP binaries, Event ID 1035, PCR drift against baseline.
• Anything a privileged boot stage executes or parses needs a signature or a measurement. If a blob genuinely can't be signed, extend it into a PCR.

What I want to argue about in the comments: when did you last verify your attestation policy actually fails when it should, by feeding it a deliberately misconfigured machine?

Longer writeup with the full taxonomy and checklist: https://axeploit.com/blog/the-signature-was-valid-and-the-boot-was-still-compromised