The Signature Was Valid and the Boot Was Still Compromised

On June 9, 2026, two Secure Boot vulnerabilities were published to the National Vulnerability Database on the same day. Neither involves broken cryptography. In both cases, signature verification did exactly what it was designed to do, and attacker-controlled code still ran before the operating system.

That should reorganize your priorities. If your mental model of Secure Boot risk is "someone breaks the math," you are defending a layer attackers have largely stopped bothering with. The failures that matter live in the enforcement logic wrapped around the signatures, and these two CVEs are clean specimens of the two dominant failure classes.

Two CVEs, zero broken ciphers

CVE-2026-45588: the check that didn't enforce

Microsoft attributes this Windows Secure Boot bypass to a protection mechanism failure, CWE-693: the mechanism does not correctly enforce the trust decision it was designed to make. Exploitation is local, low complexity, requires high privileges, and needs no user interaction.

The attack pattern is instructive. An attacker with administrative rights stages modified boot components or manipulates Secure Boot policy structures, then reboots. On the next start the tampered components execute even though Secure Boot is enabled, producing persistence that survives OS reinstallation. The footprint is wide: Windows 10 from 1607 through 22H2 across x86, x64 and ARM64, Windows 11 23H2 through 26H1 on x64 and ARM64, and Windows Server from 2012 through 2025. There is no public exploit code, and it was not in the CISA Known Exploited Vulnerabilities catalog at publication time.

CWE-693 is the failure mode I find most often in boot audits. Verification happens. A trust decision gets made. Somewhere downstream, nothing enforces it. The crypto report says pass and the boot log says owned.

CVE-2026-8863: the signed shim that stopped checking

The second bug hits multiple Microsoft-signed UEFI shim bootloaders. Their own signatures are fine. The problem is improper validation logic inside the shim, which lets an attacker bypass signature enforcement and load unsigned or untrusted code during boot. Because the shim binaries remain validly signed under the Microsoft UEFI CA, firmware keeps accepting them until the DBX revocation list is updated. Windows systems trusting the Microsoft UEFI CA are affected, and so are Linux distributions using Microsoft-signed shim.

Exploitation requires local administrative privileges or equivalent ability to write to the EFI System Partition: stage the vulnerable signed shim, configure firmware to chain to it, reboot. Persistent pre-OS foothold, no user interaction beyond the reboot.

Note what mitigation actually requires. Not one fix but a coordinated set: the Microsoft security update plus a UEFI DBX update revoking the vulnerable shim images, an inventory of Linux systems using Microsoft-signed shim (moved to a non-revoked vendor build), and tighter control over local admin and ESP write access. Detection follows the same shape: hash-compare shimx64.efi, shimia32.efi and shimaa64.efi against vendor-shipped baselines, confirm the latest DBX update is present, cross-check shim version with mokutil --sb-state or bcdedit /enum firmware, and forward TPM PCR 0-7 measurements for drift analysis.

This is the second class: signed but dangerous. A signature answers "who shipped this binary." It says nothing about whether the binary enforces policy.

A UK tech outlet is also reporting a UEFI flaw that bypasses Secure Boot on a reported 200,000 Framework laptops. The article body sits behind a JavaScript and cookie check, so only the headline is verifiable right now, and you should treat the number as a headline claim. If the reporting holds, it is the same class again, this time in OEM firmware rather than a Microsoft-shipped component.

A working taxonomy of non-cryptographic failure

Mapping these incidents to root causes gives you five classes worth auditing for:

Protection mechanism failures (CWE-693). The check exists on paper; the enforcement never fires. CVE-2026-45588.
Signed-but-dangerous tooling. Validly signed components with broken validation logic or excessive capability. The 8863 shims, and the reported Framework issue if it confirms.
Rollback gaps. CVE-2026-8863 is only fixed on a given machine when the DBX update actually lands there. Revocation that exists on a server somewhere but not on the device is no revocation. The embedded analog is an anti-rollback counter that exists in silicon but was never wired into the boot decision.
Attestation policy blind spots. Measured boot only catches what the policy measures. Everything else attests cleanly.
Misconfigured debug and fuse states. Production units with debug enabled, secure-boot fuses never blown, keys left in a test state.

None of these touch a cipher. All of them hand an attacker pre-OS execution.

The two objections I keep hearing

"These bugs need admin rights." True, and irrelevant to their severity. Admin is the staging cost; the payout is persistence that survives a full OS reinstall. Once boot components are tampered with, reimaging the disk changes nothing, and your incident response shifts from "reimage and move on" to firmware-level remediation. Treat these as firmware incidents, not local privilege noise.

"I build embedded systems, none of this is my stack." The classes are stack-independent. Read Microsoft's Azure attestation measurement list, which covers db and dbx digests, KEK and PK signatures, Secure Boot state, debugging disabled on production machines, and a code integrity policy for post-boot drivers and kernel-mode executables. That is an embedded audit checklist wearing cloud clothes: key store integrity, fuse state, debug lockdown, rollback hygiene, verified handoffs.

Azure's attestation design shows what detection looks like

The Azure measured boot and host attestation documentation is worth studying because it shows the detection layer working as intended. The TPM records boot measurements as hash-chained values in Platform Configuration Registers: you take the previous measurement's hash, add it to the next measurement, and hash the union. Order matters, and history cannot be quietly rewritten, because the TPM exposes PCRs only through read and extend operations. Attestation is the host proving its configuration state using its boot log, the TCGLog. The Host Attestation Service validates that compliance statement against an attestation policy, runs in a locked-down environment inside each Azure cluster, and uses a PKI to validate the provenance of requests before issuing identity. Post-attestation credentials are sealed to specific PCR values and to the requesting host, which resists man-in-the-middle and spoofing attacks.

The failure path is the part defenders should copy. If a host arrives from the factory with a security misconfiguration or is tampered with in the datacenter, the TCGLog carries indicators of compromise, attestation fails, all communication to and from the host is blocked, and an incident workflow starts. Microsoft investigates and completes a post-mortem before that host rejoins the fleet and takes customer workloads.

Now count how many of Azure's measurements are cryptography. Essentially none. They are configuration state, because that is where Secure Boot actually breaks. The caveat cuts the other way too: anything absent from the policy passes attestation every time. If your policy never checks debug state, a machine that left the factory with debugging enabled will attest cleanly forever.

The embedded audit checklist, in priority order

Coverage of these bugs is almost entirely Windows and x86 enterprise, so here is the mapping for embedded targets, in the order I would run it.

1. Debug interfaces first. Confirm JTAG and SWD are locked or disabled on production units pulled from inventory, not on dev boards. If you support field debug through certificates or a challenge-response unlock, try to bypass it yourself. One open debug port makes every downstream stage decorative. Azure checks "debugging disabled" on production machines for a reason.

2. Key burning and fuse state. Verify the root key hash is actually fused, the secure-boot-enable fuse is blown, and the part cannot be coaxed back into a non-verifying mode. Sample real units off the line. A fuse map reviewed in a design document is intent, not evidence.

3. Anti-rollback that survives attack testing. The counter must increment on every security-relevant update, old images must be refused afterward, and the counter itself must resist rollback. On UEFI-based embedded targets the same muscle is DBX hygiene: confirm the latest Microsoft DBX update is present (an explicit CVE-2026-8863 mitigation) and prove you can push a revocation to deployed units.

4. Every handoff verifies something. Staged verification fails at the seams. The ROM verifies the bootloader, the bootloader verifies the kernel, and then the kernel loads an unsigned device tree or initramfs. Decision rule: anything a privileged stage executes or parses needs either a signature or a measurement. If a blob genuinely cannot be signed, extend it into a PCR so attestation catches the drift.

5. Measure, then validate the measurements. Keep known-good PCR baselines and diff on a schedule. For mixed fleets, borrow the CVE-2026-45588 indicator list: unexpected modifications to UEFI variables or the db, dbx, KEK and PK stores; unsigned or unexpected BCD entries; changes to bootmgfw.efi or winload.efi outside Windows Update events; new EFI binaries in the ESP that did not arrive as part of a Microsoft-signed update; Event ID 1035; TPM event log PCR discrepancies against baseline.

6. Inventory every signed third-party boot component. Know which signed shims and loaders your fleet trusts, and check them:

bash

# On a known-good unit, baseline the shim hashes
sha256sum /boot/efi/EFI/*/shimx64.efi

# Fleet-wide: compare hashes, confirm state
mokutil --sb-state          # Linux
bcdedit /enum firmware      # Windows

Forward PCR 0-7 measurements for drift analysis, per the 8863 detection guidance.

7. Rehearse revocation before you need it. The real-world fix for 8863 is an OS patch plus a coordinated DBX push plus a Linux shim inventory, executed together. If you have never run that drill against your own fleet, this item is your audit finding.

Key takeaways

Both June 2026 Secure Boot CVEs broke the enforcement logic around signatures, not the signatures themselves. Audit the enforcement layer, because that is where attackers are working.
A validly signed component with broken validation is an exploit delivery vehicle. Only revocation stops it, so your DBX and anti-rollback paths need to work under pressure, not just in the datasheet.
Attestation only sees what policy measures. The Azure list (db and dbx digests, KEK and PK signatures, Secure Boot active, debug disabled, code integrity policy) is the minimum, and whatever your policy omits is your blind spot.
On embedded targets, the first three audit items are debug port lockdown on production units, verified key burning, and anti-rollback you have personally tried to defeat.
Persistence below the OS survives reimaging. Treat these bugs as firmware incidents, even the ones that need admin to stage.