A decade-old hole in the boot chain
On July 14, 2026, ESET researcher Martin Smolár disclosed that 11 old, Microsoft-signed Linux UEFI "shim" bootloaders — version 0.9 and earlier, some dating to 2015 — could be used to bypass Secure Boot on almost any UEFI-based PC, regardless of which operating system it runs (ESET, welivesecurity.com). The shim is the small first-stage loader that lets Linux distributions boot on machines that trust Microsoft's "Microsoft Corporation UEFI CA 2011" certificate. Because that certificate is embedded in the firmware of most PCs sold in the last fifteen years, any of the 11 flawed shims — regardless of which vendor originally shipped it — could be dropped onto a target system and used to load a bootkit like BlackLotus or HybridPetya before Windows, or any OS, ever starts (The Hacker News).
The flaw is tracked as CVE-2026-8863 and CVE-2026-10797 in a joint advisory from the CERT Coordination Center, which lists affected bootloaders from Red Hat, Oracle Linux, openSUSE, Baramundi, Blancco WipeDrive, and Finland's national Abitti exam-testing image, among others (CERT/CC, VU#616257). Microsoft revoked the 11 binaries by adding their signatures to the UEFI Forbidden Signature Database (DBX) in its June 9, 2026 Patch Tuesday update, carried forward in the July update. Because the shims were never individually vulnerability-scanned before 2017 — when the community-run shim-review process began — nobody can say with confidence how many other pre-2017 shims with the same class of flaw remain silently trusted (Help Net Security).
Coordinated disclosure, working as designed
The policy-relevant fact here isn't the vulnerability itself — old, unmaintained signed binaries accumulating in a firmware trust store is a familiar supply-chain problem. It's the timeline. ESET reported its findings to CERT/CC on February 16, 2026. Microsoft shipped the DBX revocation on June 9, 2026 — under four months later — and ESET withheld public technical detail until July 14, five weeks after the patch was broadly available. That is close to a model coordinated-disclosure cycle: private reporting, a fix pushed through the actual distribution channel (Windows Update, cascading to firmware DBX updates other OSes can also consume), and only then public detail.
This matters because the technical fix here isn't trivial. A DBX update has to propagate to millions of individually-configured UEFI firmware implementations without bricking machines that still legitimately rely on an old shim for a recovery tool or embedded appliance — which is exactly why CERT/CC's advisory tells administrators to update their authorized signature databases before applying the revocation, not after. A four-month window from private report to shipped fix, for a defect requiring firmware-level coordination across every major OS and hardware vendor, is a reasonable outcome for a bug class this entangled.
The regulatory instinct, steelmanned
There is a genuine case for tighter mandates here, and it deserves a fair hearing before dismissal. The EU's Cyber Resilience Act — Regulation (EU) 2024/2847 — begins requiring manufacturers to report actively exploited vulnerabilities to ENISA and national CSIRTs starting September 11, 2026, with full vulnerability-handling and lifecycle obligations phasing in by December 11, 2027 (European Commission, Cyber Resilience Act). Proponents of that kind of regime would point to exactly this case as the argument for it: the shim-review project's own visibility gap before 2017 means an unknown number of vulnerable, Microsoft-trusted bootloaders may still be circulating with no public inventory. A mandatory, machine-readable software bill of materials for boot-chain components — and a legally enforceable reporting clock — would in principle close that blind spot faster than researcher goodwill and voluntary CERT/CC coordination.
That argument has real force where the underlying transparency problem — nobody centrally tracks every shim ever signed — is exactly what an SBOM-style requirement is built to fix. It is weaker as an argument for mandating disclosure timelines specifically, which is where the CRA's design gets closer to the wrong lever for this bug class.
Why a hard mandate would misfire here
A statutory disclosure deadline is built for a single vendor patching a single product. This vulnerability required Microsoft, a dozen affected Linux distribution maintainers, CERT/CC, and firmware OEMs to coordinate a shared revocation list before any of them could safely publish — publishing early, or on a fixed legal clock, risks weaponizing detail before the DBX update reaches enough machines to matter. The four-month interval wasn't drift; it was the minimum time needed to build and stage a fix that thousands of independently-configured firmware stacks could absorb without breaking boot on legitimate legacy systems.
The proportionate regulatory response isn't a rigid deadline — it's targeted transparency infrastructure: mandatory, queryable logs of what's been submitted to programs like shim-review, extended retroactively to pre-2017 signings, paired with narrowly-scoped SBOM rules for boot-critical components specifically (not blanket software categories). That gives researchers and CERTs the inventory the CRA's proponents rightly want, without forcing a fixed reporting clock onto a bug class where premature disclosure is itself the risk. Regulators drafting CRA implementing guidance ahead of the 2026-2027 phase-in should take this case as evidence for better inventories, not tighter clocks.