Eleven vulnerable UEFI bootloaders expose Secure Boot bypass risk

Security researchers have identified eleven vulnerable UEFI shim bootloaders that were signed by Microsoft but later revoked due to security flaws, yet remained trusted on systems for years, effectively allowing attackers to bypass Secure Boot protections. Infosecurity Magazine reported on 15 July 2026 that these bootloaders, some dating back several years, were never properly removed from the trusted boot chain on many systems, meaning that an attacker with administrative access could use them to load unsigned or malicious code during the boot process, even on systems where Secure Boot was enabled and believed to be protecting the system. The issue highlights a gap in how revoked bootloaders are managed across the industry, with many systems not receiving or applying the necessary updates to remove trust from these components.

Why this matters for UK organisations

Secure Boot is designed to ensure that only trusted software can run during the system startup process, protecting against bootkits and rootkits that load before the operating system. However, this research shows that the revocation process for compromised or vulnerable bootloaders has not been consistently applied, leaving a window of opportunity for attackers who gain administrative access to a system. While exploiting this requires an attacker to already have significant access to a machine, it provides a way to establish deep persistence that is difficult to detect and remove, even with endpoint detection tools. For organisations, this is a reminder that firmware and boot-level security depends on keeping revocation lists up to date, not just applying operating system patches. It also highlights that security at the firmware level is often less visible and less well understood than security at the operating system or application level, yet it is a critical foundation for the entire security stack.

What to review

Organisations should review whether systems are receiving and applying UEFI firmware updates and revocation list updates, not just operating system patches. Ensure there is a process for managing firmware updates across the estate, particularly for servers and critical infrastructure where boot-level compromise would have significant operational impact. This is also a useful conversation to have with hardware vendors and managed service providers about how firmware security is maintained and how revocation lists are kept current. For organisations that manage their own hardware, check whether firmware update processes are documented, tested and applied regularly, and whether there is visibility into which firmware versions are running across the estate. For organisations that rely on managed services or cloud infrastructure, this is a useful question to ask about how the provider manages firmware security and whether revocation lists are kept up to date. This is also a reminder that defence in depth remains important, even on systems where Secure Boot is enabled, an attacker who gains administrative access can still cause significant harm, so limiting administrative access, monitoring for unusual activity, and maintaining strong identity controls remain critical layers of defence.

Source: Infosecurity Magazine