Eleven Old Microsoft-Signed UEFI Shims Enable Bypass of Secure Boot on Linux Systems Still Trusting Microsoft Corporation UEFI CA 2011
Eleven legacy UEFI shim bootloaders, all signed by Microsoft and dating back to version 0.9 or earlier, can be exploited to bypass UEFI Secure Boot on systems whose firmware still trusts the Microsoft Corporation UEFI CA 2011 certificate. The vulnerability allows an attacker who can place one of these old but validly signed shims into the boot chain to execute arbitrary code before the operating system starts, effectively turning a trusted loader into a vector for pre-OS compromise.
The risk is comparable to a BYOVD (Bring Your Own Vulnerable Driver) attack but occurs at the firmware level. An attacker does not need the original software that shipped the shim; it is sufficient for the firmware to accept the signature and for the attacker to modify the EFI partition, disk, or boot media. Because execution happens before the OS loads, traditional endpoint detection and response telemetry often remains blind to the activity, making persistence via UEFI bootkits significantly easier.
The affected shims are linked to multiple distributions and third-party tools, including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE, baramundi Management Suite up to 2024R1, WipeDrive versions 8.0.0 through 8.1.3, PC Doctor Service Center, and Abitti 1. Two CVEs—CVE-2026-8863 and CVE-2026-10797—cover different portions of the problem.
Mitigation Strategy
Microsoft has already published revocation entries for the vulnerable shims in the DBX database. Once applied, firmware will refuse to execute the old binaries even though they carry a valid signature. However, simply revoking the hashes without preparation can prevent systems from booting if older components remain in the chain.
The recommended sequence is therefore:
- First update shim, GRUB, and all other boot components to current versions that include SBAT (Shim Boot Application Table) protections.
- Only after these updates are verified, deploy the DBX revocations.
- Test the changes on a representative subset of machines before broad rollout.
- Inventory rescue media and maintenance USB drives, because any that still contain old shims will become unusable after revocation.
Administrators can verify the final state of Secure Boot variables using tools such as Check UEFISecureBootVariables on Windows or uefi dbx audit on Linux. It is also important to note that the scheduled expiration of the Microsoft UEFI CA 2011 certificate on 27 June 2026 does not automatically invalidate previously signed binaries; only an explicit DBX entry removes trust.
More information is available from The Hacker News, CERT Coordination Center (VU#616257), NIST NVD (CVE-2026-8863), and Help Net Security.
Related articles
Fuzzilli vs BigSleep: 37 and 45 Vulnerabilities Found in V8 Over Six Months with 25% Overlap
Google's Project Zero compared two automated vulnerability discovery tools targeting the V8 JavaScript engine in Chrome. The generative fuzzer Fuzzilli identified 37 actionable vulnerabilities over six months, while the LLM-based agent BigSleep found 45. Only about 25% of the vulnerabilities overlapped between the two systems. Additional experiments on historical bugs from 2023 onward showed a theoretical overlap of around 60%. The analysis indicates that fuzzing and LLM agents complement each other rather than one replacing the other. Researchers recommend using both approaches together to maximize coverage of complex bugs in well-tested software like V8.
ISPsystem Publishes Detailed Timeline of VMmanager 6 Attack and Vulnerability Analysis
ISPsystem has released a comprehensive post detailing a recent security incident targeting its VMmanager 6 virtualization management platform. The company outlines the chronology of the attack, the specific vulnerabilities exploited by threat actors, and the current mitigation status. The incident has sparked significant discussion within the professional hosting and virtualization community. ISPsystem emphasizes transparency and provides technical breakdowns to help users understand the attack vectors and required defensive measures. The post covers how the attackers gained initial access and the subsequent impact on managed virtual environments.
Google Fixes 52 Vulnerabilities in Chrome Including Four Critical Issues
Google has released security updates for its Chrome browser that address a total of 52 vulnerabilities. Four of these flaws received the highest severity rating of Critical. The updates were issued on October 27, 2026, for Windows, macOS, and Linux platforms. The critical vulnerabilities include memory corruption in the file system, input validation issues in the file API, problems in the Skia graphics library, and a Use After Free flaw in the Layout component. Specific CVEs patched are CVE-2026-118306, CVE-2026-118331, CVE-2026-118348, and CVE-2026-118344. The remaining 48 vulnerabilities received lower severity ratings but were still addressed in the same release.
CISA Adds Brotli and Adobe Commerce Flaws to Known Exploited Vulnerabilities Catalog
The U.S. Cybersecurity and Infrastructure Security Agency has added two vulnerabilities to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. CVE-2026-111497 affects Google’s Brotli data compression library and can lead to code execution, information disclosure, or denial of service when specially crafted compressed data is processed. The flaw impacts any software that incorporates the Brotli decoder for decompression tasks, prompting vendors to release updates. CVE-2026-48356 resides in the file upload functionality of Adobe Commerce and Magento, allowing attackers to exploit improper handling during upload operations. CISA issued the alert on October 27, 2026, urging organizations to apply patches immediately to mitigate ongoing attacks. Related advisories also reference Brotli fixes in PHP and other products that bundle the library.