A legitimately signed Lenovo driver has been identified as a viable Bring Your Own Vulnerable Driver attack vector, giving attackers without administrative privileges the ability to terminate CrowdStrike Falcon and other endpoint detection and response products at the kernel level — using a component that Windows driver signature enforcement treats as fully trusted.
Security researcher Jehad Abudagga disclosed the finding on May 22, 2026. The driver in question is BootRepair.sys, a digitally signed Lenovo component with SHA-256 hash 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946.
The IOCTL 0x222014 Vulnerability in BootRepair.sys
The vulnerability centers on a single exposed control code. BootRepair.sys processes IOCTL control code 0x222014, which accepts a process identifier and passes it directly to the Windows kernel API ZwTerminateProcess. There is no access control verification before that call executes. Any process on the system — regardless of privilege level — can open a handle to the driver and send the IOCTL with a target PID to kill that process at ring-0.
This means the flaw is not limited to administrators. An unprivileged user account or a process running with standard user permissions can load the driver via the Service Control Manager and issue the termination call. The target process — including a running CrowdStrike Falcon sensor — dies without generating an access-denied error, without user confirmation, and without triggering standard API monitoring hooks that would flag a direct process termination attempt from userspace.
No CVE has been assigned for this vulnerability. The driver lacks proper access controls on the interface that accepts the IOCTL, which is the core defect: a kernel-level operation callable with no privilege verification.
The Attack Chain: Drop, Load, Terminate, Proceed
The practical attack sequence is short. An attacker drops BootRepair.sys to disk — which will pass allowlisting checks because it carries a legitimate Lenovo digital signature — loads it as a kernel driver service through the Service Control Manager, queries or enumerates the PID of the CrowdStrike Falcon sensor process, and issues IOCTL 0x222014 with that PID. Falcon terminates. With the endpoint’s detection layer removed, the attacker proceeds to credential theft, lateral movement, or ransomware deployment without generating the telemetry that would ordinarily trigger an alert.
The attack chain does not require the attacker to exploit any ring-0 code directly. The signed driver performs the privileged operation on the attacker’s behalf. That delegation is why BYOVD attacks are effective: the attacker never writes or runs unsigned kernel code. Everything is handled by a driver Windows already trusts.
Why Signed Lenovo Drivers Pass Every Allowlist Check
The reason BootRepair.sys is an effective BYOVD vehicle is precisely because it is signed. Windows driver signature enforcement, enterprise allowlisting policies, and many endpoint security products treat signed drivers as inherently safe. The Lenovo signature means BootRepair.sys is not blocked by the same controls that would catch an attacker-written kernel module.
BYOVD attacks have become the dominant EDR evasion technique for this reason. Rather than attempting to write kernel exploits — which require finding and triggering a ring-0 vulnerability in a frequently patched component — attackers simply ship a known-good signed driver that exposes a dangerous interface. The attack surface is not a software bug in the traditional sense. It is a design flaw in a trusted component that was never intended to be used this way.
BootRepair.sys joins a documented list of legitimate signed drivers that have been weaponized similarly: mhyprot2.sys, gdrv.sys, and others have appeared in published BYOVD attack chains over the past several years, primarily deployed by ransomware affiliates seeking to disable security tools before payload execution.
Exposure for CrowdStrike Falcon Users and Other EDR Deployments
Endpoint protection platforms that cannot block unsigned or non-allowlisted driver loading are exposed to this technique. Organizations running CrowdStrike Falcon or other major EDR products need to evaluate whether their driver control policies would prevent BootRepair.sys from loading in an attack scenario, given that the driver is legitimately signed.
Endpoint security vendors have increasingly responded to BYOVD proliferation by maintaining driver-specific blocklists — databases of known vulnerable signed drivers whose IOCTLs have been weaponized. Microsoft maintains a blocklist through Windows Defender Application Control, and CrowdStrike and other vendors maintain their own supplemental lists. Adding BootRepair.sys to those blocklists is the most direct mitigation.
No Patch Available at Time of Disclosure
No patch from Lenovo and no response from Lenovo were noted in Abudagga’s disclosure published May 22, 2026. Organizations that cannot immediately apply driver blocklist updates may be able to detect the technique through endpoint security platforms that monitor for unexpected IOCTL patterns issued to drivers not normally active on the system, or through alerting on Service Control Manager operations that load BootRepair.sys outside of an authorized maintenance context.
The growing driver blocklist problem facing endpoint vendors is structural: every digitally signed driver from every hardware vendor that exposes an insecure kernel I/O control interface adds to the potential BYOVD attack surface. As long as code signing remains the primary trust signal for kernel-level code, vendors who sign drivers with dangerous exposed interfaces — even if those interfaces were never intended for external callers — will continue to contribute to this class of attack.
