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
Fuzzy Logic in Cybersecurity: Reducing Vulnerability Queue by 7.5 Times with CVSS, EPSS and FSTEC Comparison
An information security specialist has developed a fuzzy logic system that prioritizes vulnerabilities far more effectively than traditional scoring methods. The approach uses linguistic variables and membership functions to handle the inherent uncertainty in exploitability and impact assessments. By integrating EPSS probability data with CVSS impact scores and vulnerability age, the model reduces the actionable backlog by a factor of 7.5. The implementation relies on the Mamdani inference algorithm and trapezoidal membership functions to produce smooth, human-interpretable urgency ratings. Detailed coverage checks and rule-base validation ensure no gaps exist in the decision space. Real-world testing on CVE-2025-49113 in Roundcube Webmail demonstrated practical advantages over rigid threshold logic. The method is positioned as a practical enhancement rather than a replacement for existing standards.
VLC Media Player Hit by Two Memory Corruption Flaws Exploitable via Malicious PNG and Rogue RealRTSP Server
Two vulnerabilities have been discovered in the VLC media player that allow out-of-bounds memory access. The issues affect versions from 3.0.0 through 3.0.23. CVE-2026-56711, rated 8.6 on CVSS 4.0, stems from an integer overflow when calculating image buffer sizes in PNG files, enabling attackers to trigger writes beyond allocated memory simply by opening a crafted image or loading it from a playlist. CVE-2026-73324, scored 6.9, resides in the RealRTSP module and permits a malicious server to send an oversized response string that causes reads past the end of a buffer due to a missing null terminator. Both flaws are present in official VideoLAN builds, although some distributions may exclude the RealRTSP component. No special configuration or plugins are required to trigger the issues. Until patched releases appear, users are advised to avoid opening images or playlists from untrusted sources and to refrain from connecting to unknown RealRTSP streams.
September Windows 11 Security Update KB5124008 Breaks Always On VPN Certificate Authentication
The September security update KB5124008 for Windows 11 has introduced a regression that disables Always On VPN connections using certificate-based authentication. The issue affects devices running Windows 11 versions 24H2 and 25H2 that connect to Remote Routing and Access Service (RRAS) and Network Policy Server (NPS) instances on Windows Server 2019. VPN profiles deployed via Microsoft Intune are impacted, with the failure occurring during the certificate negotiation phase of the IPsec connection. Users confirm the problem is reproducible: the VPN works before the patch, stops after installation, and resumes after patch removal and reboot. Microsoft has not yet acknowledged the regression or released a fix, leaving administrators to pause deployment through WSUS or Intune and open support cases with client and NPS logs. A potential workaround involves switching profiles to EAP-TLS, though its reliability remains unconfirmed.
API Token Lifecycle: From Issuance to Revocation and Secure Management
The article provides a comprehensive examination of the full API token lifecycle in browser-based applications, emphasizing that signatures alone cannot prevent token theft. It details risks introduced at issuance, storage, transmission, and revocation stages, including improper OAuth grant types and long-lived tokens. Key recommendations include short-lived access tokens, atomic refresh token rotation, and the use of Authorization Code Flow with PKCE for public clients. Storage advice strongly discourages localStorage and sessionStorage in favor of HttpOnly cookies or a Backend-for-Frontend pattern that keeps real tokens on the server. The piece also covers CSRF protections, rate limiting on authorization endpoints, and the advantages of signed client assertions over static secrets. Overall, it stresses that token security depends on the entire lifecycle architecture rather than cryptographic strength alone.