Secure Boot is the security check that runs before Windows even starts. Its job is to verify that every piece of firmware and boot code loading during startup carries a valid digital signature, blocking unsigned or tampered code from running before your operating system takes over. Researchers at ESET have now shown that this check has been trivial to bypass for 13 of the 14 years the mechanism has existed. (Source: Arstechnica)

The weakness lives in components called shims, small pieces of signing software Microsoft created to extend Secure Boot to Linux devices and utility tools. ESET found 11 firmware images—one dating back to 2013—that Microsoft knew were defective but kept signing anyway. Because these old, forgotten shims still carry Microsoft's valid signature, an attacker can load one and use it to circumvent the entire Secure Boot chain.

One example is the Oracle shim, which signs a binary vulnerable to CVE-2015-5381. ESET's Martin Smolár said the skill needed to exploit it is low—simple enough for novice attackers using scripted, hack-by-numbers techniques. Other shims fail to enforce protections like MOK deny-lists and SBAT that arrived after those shims shipped, and some contain flaws in their own code.

Once an attacker uses one of these shims, they can install malicious firmware that loads early in the boot process and survives an OS reinstall or even a hard drive replacement. That persistence is the part that matters to your firm: firmware-level malware sits below the operating system, so reimaging a machine or swapping the disk does not remove it.

The threat reaches both Windows and Linux systems, since the shim installs on either. Windows 11 Secured-core PCs in their default configuration are likely not affected. If you have already installed Microsoft's June update batch, you are no longer exposed to this specific bypass.

Business and Operational Risk of Secure Boot Failure

What makes this bypass dangerous is where it lives. An attacker who uses one of these old signed shims installs malicious code at the firmware level, below your operating system and below the tools you rely on to catch intrusions. This code loads before Windows or Linux starts, which means it runs before your endpoint detection software, your antivirus, and your logging agents ever come online.

Practically, that gives an attacker three things you can't easily undo. The malicious firmware persists after a full OS reinstall and even after you swap the hard drive, because it sits in the UEFI on the motherboard, not on the disk. Your standard remediation playbook—wipe and reimage—does not remove it.

Second, it hides from the tools you trust. Because the malware controls the boot process before your security stack loads, it can conceal itself from endpoint detection and from forensic tools that assume the operating system underneath them is honest. If you're investigating a breach, your evidence collection runs on a platform the attacker already owns.

Third, the skill barrier here is low. ESET's researcher described the technique as simple enough for novice attackers, and one of the vulnerable shims signs a binary exploitable via CVE-2015-5381, a flaw rated as low-difficulty to exploit. This is not a capability reserved for nation-state actors.

"This is a solid rebuke of the entire secure boot model," said HD Moore, a firmware security expert and CEO of runZero, citing Microsoft acting as the de facto root of trust for the whole UEFI platform.

For non-technical stakeholders, the compliance angle matters. If your organization tells auditors, insurers, or customers that endpoints are hardened and that Secure Boot is an active control, that claim has been inaccurate for these affected systems. Frameworks and cyber-insurance questionnaires frequently ask whether Secure Boot is enabled; answering "yes" no longer guarantees the protection you assumed you had on vulnerable machines.

The exposure crosses departments. Consider where you depend on firmware integrity:

• IT and endpoint fleets: Both Windows and Linux machines are affected, because the shim installs on either operating system. A mixed fleet is a mixed problem.
• Incident response and forensics: A bootkit that survives reimaging changes the cost and duration of every investigation. Dwell time extends because the attacker keeps a foothold you cannot see or wipe by conventional means.
• Any system treated as "clean" after remediation: If a compromised machine was reimaged and returned to service, it may still carry the implant.

There is one meaningful limit worth naming for your planning. Windows 11 Secured-core PCs in their default configuration are likely not exposed, and Windows systems that received Microsoft's June update are no longer vulnerable. That narrows the affected population, but it does not cover older Windows hardware, unpatched systems, or the Linux side of your estate.

The cost story is about detection failure and recovery difficulty rather than an immediate flashy breach. An attacker with firmware-level persistence can read data, maintain access across rebuilds, and stay hidden while your monitoring tools report clean. For a regulated business, that combination means a longer breach window, harder forensic accounting of what was accessed, and remediation that may require firmware reflashing or hardware replacement rather than a routine reimage.

Technical Mechanics of CVE-2015-5381 Exploitation

The core of this attack chain sits in CVE-2015-5381, a vulnerability in a binary that the Oracle shim signs and authorizes.

The mechanism works because the shim was designed to hand off trust. A shim validates a second-stage bootloader against Microsoft's key, then that bootloader loads the kernel. When the shim authorizes a component that is itself vulnerable—or when the shim fails to enforce newer protections like MOK deny-list enforcement and SBAT enforcement—the entire chain of digitally signed firmware can be subverted. An attacker uses the still-signed shim as a legitimate entry point, then abuses the flaw in the component it trusts.

The failure in the validation logic is not a broken signature check. The signatures are valid. Microsoft signed these images and never revoked them, so from Secure Boot's perspective everything in the chain is authentic. The problem is that authentic and safe are not the same thing here—the signed code contains exploitable bugs, and some shims lack the protections that came into effect after they were released.

Prerequisites lean toward local or administrative access. To place a rogue shim onto a system, an attacker generally needs the ability to write to the firmware or the EFI system partition, which typically requires elevated privileges on an already-compromised host. This is not a remote, zero-click path. It is a persistence and privilege-consolidation technique used after initial access, mapping to MITRE ATT&CK T1542.001 (Pre-OS Boot: System Firmware) and related bootkit tradecraft.

What that means operationally: this vulnerability is most dangerous as the second act. An intruder who already has a foothold uses one of these old shims to plant code that reloads on every boot, ahead of the operating system. That converts a temporary compromise into a durable one.

Forensic artifacts cluster around the boot path rather than the running OS. Investigators should expect to find:

• An unexpected shim binary on the EFI system partition—particularly an old, deprecated image such as one dating to 2013, which has no business on a modern system.
• A second-stage bootloader known to be vulnerable to CVE-2015-5381, authorized by the Oracle shim.
• Boot components that continue to load even after the top-level certificate that signed them has expired—an inconsistency HD Moore of runZero specifically flags as a design failure.
• Revocation status mismatches, which can be surfaced by comparing the system's UEFI forbidden-signature database against expected state.

A complicating factor for responders: certificate expiration does not clean this up. Even though the Microsoft certificate that signed these shims expired late last month, that expiration is not sufficient to revoke the specific images ESET identified. A machine can still boot the old, vulnerable shim.

"The end result is a huge number of unknown (to everyone but Microsoft) signed things that bypass Secure Boot—some of which can then be used to boot other things," said HD Moore, "and both have normal security bugs and other mistakes that mean they can be used to boot nearly anything."

On the tooling side, the report does not publish a packaged exploit, but the low skill bar and the public availability of the affected images mean the barrier to reproduction is minimal. For incident responders, the practical takeaway is that a signed-and-valid boot component is not evidence of a clean system—the presence of a known-vulnerable shim in the boot chain is itself the indicator worth chasing.

Detection and Forensic Indicators for CVE-2015-5381 Compromise

The single most important detection step is to verify Secure Boot's revocation state on any system you cannot easily reimage. Run the uefi-dbx-audit script referenced in ESET's report to confirm whether the vulnerable shims and their associated revocation entries are present in your firmware's forbidden signature database (dbx). If the entries are missing, the door ESET described is still open on that machine.

Following the NIST Cybersecurity Framework, work through the functions in order, prioritizing systems where firmware persistence would be hardest to remove.

Start by identifying which of your machines are actually exposed. Windows 11 Secured-core PCs in their default configuration are largely out of scope. Any Windows host that received Microsoft's June update batch has the relevant revocation applied. For Linux fleets, cross-reference installed shim versions against the Linux Vendor Firmware Service or your distributor's advisory, and treat any host still carrying a shim signed by the now-expired Microsoft certificate as unverified.

On the detect side, focus on artifacts that survive below the operating system. Bootkit persistence at the UEFI level leaves specific traces you can hunt for:

• Unexpected changes to the boot configuration and boot order recorded in UEFI variables, particularly new or reordered boot entries that don't match your provisioning baseline.
• Firmware measurements that fail TPM attestation—compare the current PCR (Platform Configuration Register) values against a known-good baseline captured from an equivalent clean device. A mismatch in the PCRs that cover firmware and bootloader code indicates the measured boot chain no longer matches what you expect.
• Presence of the defective shims themselves on the EFI System Partition, including images that trace back to firmware releases as old as 2013.
• Shims that fail to enforce MOK deny-list or SBAT checks, since those absent protections are the mechanism a bootkit uses to load unsigned second-stage code.

Because this activity happens before your endpoint agent loads, agent telemetry alone won't catch the initial firmware write. What your EDR can catch is the behavior that precedes it—the privileged process that stages a rogue shim onto the boot partition or modifies UEFI variables. In environments Capstone manages, SentinelOne flags the userland activity that writes to the EFI System Partition or invokes firmware update interfaces, giving you an alert on the step an attacker must take before the bootkit ever gains persistence.

For the respond phase, treat a confirmed firmware anomaly differently from a routine malware detection. Reinstalling the OS or swapping the drive does not remove code that lives in the motherboard's UEFI, so a standard reimage will leave the implant in place. Isolate the host from the network, capture a firmware image for analysis, and plan for a full firmware reflash from the hardware vendor's verified image—or physical replacement where reflashing isn't supported.

Recovery means restoring a verified boot chain and confirming it stays verified. After reflashing, re-run uefi-dbx-audit to confirm the revocation entries are now present, re-take a clean TPM attestation baseline, and re-enroll the device into your attestation checks so future PCR drift raises an alert. Prioritize this rebuild sequence on domain controllers, hypervisors, and any critical infrastructure host where firmware-level persistence would give an attacker a foothold that outlives every other control you have.

Patching and System Hardening for Secure Boot Protection

The single most important patch is Microsoft's June update batch. According to ESET, any Windows user who has installed that month's cumulative updates is no longer vulnerable to the shim bypass. Install it before touching anything else, because it adds the revocation entries needed to reject the defective shims that Microsoft never pulled from circulation.

Here is the catch that changes your rollout plan: the natural expiration of the Microsoft certificate that signed these shims—which occurred late last month—does not revoke the specific images ESET identified. Waiting for certificates to lapse solves nothing. You have to push the revocation actively through updates.

Identify what you're actually running

Start by separating your fleet by operating system, because the fix path differs. Windows machines get patched through Microsoft's June updates. Linux machines need updated shims from their distribution vendor.

• Check the Linux Vendor Firmware Service (LVFS) for updated firmware and shim packages that match your hardware.
• Consult your Linux distributor directly for the corrected shim build, since not every image is distributed through LVFS.
• Inventory any utility software or third-party bootloaders that shipped their own signed shims—the Oracle shim tied to CVE-2015-5381 is one example, and others carry their own code flaws.

Protect: apply patches and confirm they took

Applying the update is only half the job. The revocation entries have to land in the firmware's forbidden-signature database, and that write can silently fail on some hardware. After patching, confirm Secure Boot is enabled and enforcing in your UEFI configuration—not merely present but set to full enforcement rather than audit or permissive mode.

On Windows, verify the state from an elevated PowerShell prompt with Confirm-SecureBootUEFI, which returns True when Secure Boot is on and enforcing. Pair this with a check of TPM status through tpm.msc so measured-boot records have a trusted place to land.

"The whole ecosystem is somewhat broken and needs a reboot."

Detect: watch for boot-level integrity drift

Firmware-level compromise sits below your endpoint agents, so ordinary tooling won't see it. Turn on measured boot and TPM-backed attestation so each boot component's hash is recorded to the TPM's platform configuration registers. When those measurements change unexpectedly, that's your signal something below the OS was altered.

Adlumin correlates boot integrity and firmware attestation telemetry across managed environments, surfacing measurement mismatches that indicate a rogue shim loaded before the operating system came online. Feed your TPM attestation logs into that pipeline so drift generates an alert instead of sitting unnoticed in firmware.

Rollout order and downtime

Prioritize by how hard the machine is to reimage and how sensitive its data is:

• Internet-facing servers and hosts with sensitive data first. These are the machines where firmware persistence would be hardest to remove and most costly if exploited.
• Critical servers that can tolerate a maintenance window next. Firmware and shim updates generally require a reboot to write revocation entries, so schedule these where downtime is acceptable.
• Standard endpoints last, batched through your normal patch cycle once servers are confirmed clean.

For systems that cannot tolerate downtime, stage the update but hold the reboot for a planned window, and track those machines separately until the revocation write is confirmed with Confirm-SecureBootUEFI. Note that Windows 11 Secured-core PCs in their default state are likely not exposed, so those can sit lower in the queue.

Recover and harden beyond Secure Boot

Because a single signing authority sitting at the root of the UEFI platform created this gap, don't treat a patched Secure Boot as the whole answer. Layer firmware attestation, measured boot, and TPM-backed integrity verification so boot state is continuously validated rather than trusted once at signing time. Keep a documented firmware-reflash procedure ready for any host where attestation reports a mismatch, since an OS reinstall alone will not clear firmware-resident code.

Why This Vulnerability Persisted Undetected for a Decade

The core failure was not a coding mistake. It was a governance gap: Microsoft, which oversees the signing of shims, kept vulnerable images signed and publicly available long after their flaws were known. At least one of the 11 defective images ESET found dates to 2013, meaning the certificate infrastructure treated a decade-old, known-broken component as trustworthy for its entire lifespan.

Part of the answer is visibility. Firmware sits below the layer where most security teams operate, so a signed shim that authorizes a vulnerable binary generates no alerts and leaves no obvious trace. Nobody was looking, because the signature itself was supposed to be the guarantee that looking was unnecessary.

The rest is complexity. Secure Boot places Microsoft as the de facto root of trust for the whole UEFI platform, and firmware security expert HD Moore argues the model does not scale and lets components boot even after top-level certificates expire.

"The whole ecosystem is somewhat broken and needs a reboot," Moore said, calling the findings "a solid rebuke of the entire secure boot model."

What this episode really demonstrates is the value of independent security research. A control marketed as a foundation of trust went unexamined at scale until an outside team catalogued the specific signed images that break it. Signatures are an assertion of trust, not a substitute for verifying that assertion holds.

The practical takeaway is a sequencing one. Any system deployed before the June patch date should be treated as potentially compromised at the firmware level, because this persistence survives a reinstall and does not announce itself. Prioritize forensic investigation of your high-value systems before you patch them, not after, so you do not overwrite evidence of an existing compromise while closing the door.