<- ALL CYBER NEWS
High
UEFI, Secure Boot, CVE-2026-8863, Bootkit, ESET, Firmware, DBX, Microsoft
UEFI Secure Boot Bypass: 11 Signed Shims (CVE-2026-8863)
CVE-2026-8863: 11 old Microsoft-signed UEFI shims allow a Secure Boot bypass and pre-OS bootkits. Microsoft revoked them via a June 2026 DBX update. How to fix.
UEFI Secure Boot Bypass: 11 Signed Shims (CVE-2026-8863)
CVE-2026-8863 is a UEFI Secure Boot bypass: eleven old Microsoft-signed shim bootloaders can be abused to run untrusted code before the operating system starts, defeating Secure Boot and enabling stealthy UEFI bootkits that load beneath the OS and its EDR. Microsoft revoked the vulnerable shims through a June 2026 DBX update, so the fix is to apply that revocation and confirm it actually landed on every device that still carries a legacy shim.
ESET researcher Martin Smolár found the 11 outdated shim bootloaders, all signed under Microsoft's "Microsoft Corporation UEFI CA 2011" certificate, that let an attacker with admin rights or boot-process access execute untrusted code during boot. That is enough to break the Secure Boot chain of trust and plant a bootkit that runs before the OS and any endpoint protection ever starts. NVD rates CVE-2026-8863 at CVSS 7.8 (High); EPSS remains low (around the 1.5th percentile) and it is not in CISA's KEV catalog, so this is a "patch on your schedule" issue rather than an active fire, but the payoff for an attacker, stealthy persistence below every OS-level defense, is why the score understates it. A related certificate-based revocation-bypass issue is tracked separately as CVE-2026-10797.
Who is affected by the UEFI Secure Boot bypass?
The exposure is on systems that still trust the vulnerable shim versions, which shipped with or were distributed by a long list of vendors: Red Hat Enterprise Linux and CentOS 7.2, Oracle Linux 7.2, openSUSE, Blancco/WhiteCanyon WipeDrive, Baramundi Management Suite, ROSA Linux, PC Doctor, Abitti, and Spyrus WTGCreator. The common hiding spots are dual-boot machines and imaging, recovery, or wipe environments, places where an old signed shim quietly persists long after the OS around it has been updated.
Attribute | Detail |
|---|---|
CVE | CVE-2026-8863 (related: CVE-2026-10797) |
CVSS / severity | 7.8 (High) |
Exploitation | No public in-the-wild exploitation; EPSS ~1.5th pct; not in KEV |
Root cause | 11 old Microsoft-signed UEFI shims allow pre-OS code execution |
Discovered by | Martin Smolár (ESET) |
Fix | June 2026 Windows DBX revocation update (and later) |
How do I fix CVE-2026-8863?
Apply the June 2026 (and later) Windows updates that push the UEFI DBX revocation list, then confirm the DBX update actually applied on each device rather than assuming it did. Retire or re-image any systems that still boot the legacy shims. One important caveat before mass deployment: test dual-boot and older Linux hosts first, because an aggressive revocation can render a machine that depends on one of these old shims unbootable. This is a change to make deliberately and verify, not a blind fleet-wide push.
Our read
A boot-level bypass that runs beneath the OS and its EDR is a textbook "understand your real risk" problem, the severity score understates it because the payoff is stealthy persistence, not a flashy exploit chain. It is the same lesson we drew from six U-Boot bootloader flaws earlier this year: firmware and boot chains are exploitable surface that annual assessments rarely touch, and DBX state is something you can only trust if you verify it. Confirming the revocation applied on every endpoint, continuously, as part of hardening, is what turns "we pushed the update" into evidence that the bypass is actually closed.
Reporting by The Hacker News and SecurityWeek; revocation detail per Microsoft MSRC; CVSS per NVD. Sources linked above.
Related: What CVSS and EPSS miss for patch prioritization · VMware CVE-2026-59309: vCenter auth bypass and VM escape
Frequently asked questions
Is CVE-2026-8863 being actively exploited?
No. There is no confirmed in-the-wild exploitation, EPSS sits near the 1.5th percentile, and it is not in CISA's KEV catalog. It requires admin rights or boot-process access to abuse, and the concern is stealthy bootkit persistence rather than mass remote exploitation.
How do I fix the UEFI Secure Boot bypass?
Apply the June 2026 (or later) Windows updates that push the UEFI DBX revocation list, and verify the DBX update actually applied on each machine. Retire or re-image systems still booting the legacy shims.
Will the DBX revocation break dual-boot or older Linux?
It can. A device that relies on one of the revoked shims may become unbootable after the DBX update, so test dual-boot systems and older Linux hosts before deploying the revocation broadly.
What is CVE-2026-10797?
A separate but related certificate-based revocation-bypass issue tracked alongside the shim flaw. Track it in addition to CVE-2026-8863 when validating that your Secure Boot revocation state is complete.