you guys - i just read this article that should genuinely be one of my all-time favorites because it's both horrifying and fascinating. microsoft built secure boot in 2012 to block bootkits like lojax, blacklotus, and moonbounce but basically left the back door wide open for a decade. why is shocking — ezet found eleven different shims going all the way back to at least 2013 that remained trusted despite being known-defective because microsoft never revoked them. these are secondary trust anchors signed by microsoft that let non-microsoft code boot, and an attacker with brief physical access could install firmware malware that survives even a full drive wipe or reinstall of windows or linux. it's the kind of vulnerability you don't think exists in production systems this large - i can't get over how old some of these are.
the reason microsoft never caught it is actually really interesting and worth explaining because there's more to it than just "someone forgot." secure boot relies on two databases: db for allowed certs and dbx for revoked ones, but the dbx has a hard cap at only 32kb — which is tiny when you have thousands of linux components. microsoft solved this with SBAT (secure boot advanced targeting) and SVN (security version number), which allow them to revoke entire versions instead of individual hashes. unfortunately here the mechanism itself was flawed because the vulnerable loader didn't support these, so it could never be added to dbx, hence why it sat there unrevoked for years while others got updated around it. basically the fix wasn't even an option for this specific set until now because they were in a blind spot created by their own architecture.
the good news is ezet flagged them both to cert and microsoft before this became public and they were finally revoked in june, but it does raise big questions about how much of our core infrastructure has quietly rotted underneath us over the last decade. i keep thinking back to lojax being used by russia state hackers in 2018 - if that exploit had been deployed against these unrevoked shims on a similar scale we'd be talking about something far bigger than just "a bug" and more like systemic firmware fragility across every pc with UEFI boot. the company hasn't explained how this could have escaped their internal auditing for so long, which is probably the question that will haunt security teams at microsoft meetings well into late 2026. anyone interested in the technical deep dive should read the full arstechnica piece because it explains sbat and dbx really clearly.
Source: https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/
the reason microsoft never caught it is actually really interesting and worth explaining because there's more to it than just "someone forgot." secure boot relies on two databases: db for allowed certs and dbx for revoked ones, but the dbx has a hard cap at only 32kb — which is tiny when you have thousands of linux components. microsoft solved this with SBAT (secure boot advanced targeting) and SVN (security version number), which allow them to revoke entire versions instead of individual hashes. unfortunately here the mechanism itself was flawed because the vulnerable loader didn't support these, so it could never be added to dbx, hence why it sat there unrevoked for years while others got updated around it. basically the fix wasn't even an option for this specific set until now because they were in a blind spot created by their own architecture.
the good news is ezet flagged them both to cert and microsoft before this became public and they were finally revoked in june, but it does raise big questions about how much of our core infrastructure has quietly rotted underneath us over the last decade. i keep thinking back to lojax being used by russia state hackers in 2018 - if that exploit had been deployed against these unrevoked shims on a similar scale we'd be talking about something far bigger than just "a bug" and more like systemic firmware fragility across every pc with UEFI boot. the company hasn't explained how this could have escaped their internal auditing for so long, which is probably the question that will haunt security teams at microsoft meetings well into late 2026. anyone interested in the technical deep dive should read the full arstechnica piece because it explains sbat and dbx really clearly.
Source: https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/