CVE-2025-1055
K7RKScan.sys -- elevation of privilege in K7 Computing antivirus driver
Summary
| Field | Value |
|---|---|
| Driver | K7RKScan.sys (K7 Computing) |
| Vulnerability Class | Elevation of Privilege |
| Exploited ITW | No |
| Vendor | K7 Computing |
Root Cause
Antivirus drivers occupy a peculiar position in the BYOVD landscape. They run at the highest privilege level, interact deeply with kernel state, and often expose device objects that any local process can open. K7 Computing's rootkit scanner driver, K7RKScan.sys, follows this pattern.
The driver exposes IOCTL handlers that can manipulate kernel state, including process termination and memory operations, but enforces no access control on who can send those IOCTLs. Any local user can open a handle to the K7RKScan device and invoke these operations. The driver treats every caller as trusted, which means any local attacker inherits the driver's kernel-level capabilities.
This is related to CVE-2025-52915, another vulnerability in the same K7RKScan.sys driver, suggesting the access control gap is systemic rather than limited to a single handler.
Exploitation
The attack is straightforward. A local attacker opens the K7RKScan device handle and sends crafted IOCTLs to the unprotected handlers. Depending on which handler is targeted, the attacker can terminate protected processes (useful for disabling security products), manipulate kernel state, or escalate privileges directly.
The irony is notable: a driver designed to detect rootkits provides rootkit-like capabilities to anyone who asks.
Exploitation Primitive
Open K7RKScan device handle (no access control)
--> crafted IOCTL to unprotected handler
--> kernel state manipulation --> privilege escalation or process termination
Broader Significance
Security product drivers are high-value BYOVD targets precisely because they need deep kernel access to do their jobs. When that access is not gated behind proper authorization checks, the driver becomes a liability rather than a defense. CVE-2025-1055 is a reminder that the "security software" label does not imply secure implementation, and defenders should apply the same scrutiny to AV drivers as to any other kernel component.