Microsoft’s Secure Boot mechanism, a cornerstone of modern PC security since its introduction in 2012, has been trivially bypassable for most of its existence. Researchers at ESET uncovered the issue. They found 11 old UEFI shim images signed by Microsoft that remained trusted despite known defects.
These shims, some dating back to 2013, allowed attackers to load malicious bootloaders without triggering any alarms. No sophisticated exploit required. Just a copy of one of those unrevoked binaries and basic knowledge of how the boot process works. The revelation, detailed in Ars Technica, sent ripples through the cybersecurity community on July 14 and 15, 2026.
But why did this persist so long? Microsoft designed Secure Boot to counter bootkits. These malicious programs infect the earliest stages of system startup. Think LoJax in 2018. Or MosaicRegressor in 2020. CosmicStrand in 2022. BlackLotus in 2023. All targeted the boot environment precisely because it runs before antivirus or endpoint detection tools load.
Shims act as secondary trust anchors. Microsoft signs them with its UEFI certificate. They then authorize other bootloaders, especially for Linux distributions needing flexibility beyond Windows defaults. The system trusts anything Microsoft vouches for. That trust chain broke because the company never revoked these flawed shims from the forbidden list known as dbx.
Thirteen out of 14 years. That’s how long the bypass remained viable. ESET researcher Martin Smolár put it plainly. “What makes these old shims dangerous is not a novel vulnerability. It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.”
The report from WeLiveSecurity explains further. One shim suffered from CVE-2015-5381, an Oracle-signed binary vulnerable to low-skill attacks. Others lacked proper MOK support or SBAT protections. Some contained their own code bugs. Microsoft had the tools—dbx updates, SBAT metadata, SVN generation numbers—to revoke them. Yet the 32-kilobyte limit on dbx space complicated matters. And the company simply didn’t act until ESET and CERT Coordination Center raised the alarm.
Microsoft finally revoked the 11 shims in its June 2026 monthly patch. Too late for systems already compromised? Possibly. The update arrived after years of quiet risk. And the company has yet to explain publicly how the lapse occurred or why it took external researchers to force the fix.
HD Moore, creator of the Metasploit framework, reacted sharply. “This is a solid rebuke of the entire secure boot model. The whole ecosystem is somewhat broken and needs a reboot.” His comment, captured in discussions across X on July 15, 2026, underscored broader doubts. Building complex boot security on a single corporate trust anchor invited failure. Silent failure at that.
Recent coverage amplified the concerns. SC Media reported on July 15 that these old Microsoft-signed UEFI applications enable full bypasses on both Windows and Linux devices. The article highlighted how every motherboard sold since 2012 implicitly trusts Microsoft’s signing authority. That trust persisted even for known-bad certificates.
So what does this mean for enterprises? Firmware attacks remain rare but devastating. They survive OS reinstalls and disk wipes. They enable persistence at the lowest level. Organizations running older hardware or those slow to apply UEFI updates face immediate risk. Even patched systems require verification that the dbx update took hold.
The discovery also exposes coordination gaps. Microsoft, hardware vendors, OS distributors and security researchers must align on revocation lists. The dbx size constraint forces tough choices about what to revoke. Prioritizing matters. Yet leaving defective shims trusted for over a decade suggests priorities slipped.
Analysts on X noted parallels to past supply-chain failures. One post from cybersecurity account @Cyber_O51NT on July 15 stated simply that ESET’s find involved “11 old, Microsoft-signed UEFI shim bootloaders that bypass Secure Boot on many systems.” Another from @Dinosn linked directly to the SC Media brief. The conversation spread quickly. Hundreds of views within hours.
Microsoft has not issued a detailed postmortem as of July 15. Its June update included the revocations without fanfare. Security teams should now audit their fleets. Tools like uefi-dbx-audit, mentioned in the original research, can check revocation status. Firmware updates from motherboard makers may also be necessary to fully enforce the new dbx.
The incident raises questions about other forgotten artifacts in the UEFI trust chain. How many more signed-but-vulnerable binaries linger? The complexity of managing shims, certificates, revocation lists and metadata across billions of devices creates fertile ground for oversights. And once again, independent researchers—not internal teams—brought the problem to light.
Users of Linux distributions that rely on these shims should pay special attention. The flexibility that shims provide also expands the attack surface. Windows systems aren’t immune either. Any machine booting via UEFI with Secure Boot enabled but not fully updated sits at risk.
Expect more scrutiny ahead. Hardware vendors may accelerate adoption of stricter SBAT implementations. Microsoft could expand its revocation processes or clarify responsibilities. For now, the fix is in. But the trust deficit grows. A security feature meant to protect the foundation of computing spent most of its life with a back door wide open. That fact alone demands attention from every CIO and security architect responsible for endpoint fleets.
The episode serves as a reminder. Foundational technologies require relentless maintenance. Assumptions about long-standing protections can prove costly. In firmware, as in so many areas, vigilance never ends.
WebProNews is an iEntry Publication