Yes. CISA added CVE-2020-17087 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows kernel contains an unspecified vulnerability that allows for privilege escalation. Any organisation running the affected product should treat remediation as urgent.
What being “exploited in the wild” means for this CVE
CISA’s KEV listing is the practical signal that matters here: it reflects confirmed active exploitation, not just theoretical risk. For a windows kernel privilege escalation issue, that means the flaw is not merely a hardening concern. It is a live prioritisation item because attackers can use it after initial access to raise privilege and deepen control of a system.
For teams triaging exposure, the first question is not whether the bug is interesting, but whether the vulnerable Windows systems are reachable, internet-facing, or already inside a trust boundary that an attacker could reach through another foothold. A privilege-escalation CVE becomes much more dangerous when combined with stolen credentials, remote access, or a separate execution path.
For current exploitation status, CISA Known Exploited Vulnerabilities Catalog is the authoritative source for whether a vulnerability has been placed in the active exploitation list, and NIST National Vulnerability Database remains the standard reference for the record itself and any linked metadata.
Why a Windows kernel privilege escalation matters operationally
A kernel privilege escalation does not usually start the breach by itself. Its value to an attacker is what it unlocks after a foothold exists: higher privileges, broader access to memory and security controls, and a better position for credential theft, persistence, or lateral movement. That is why exploited local elevation flaws are often treated as post-compromise accelerators rather than standalone defects.
In practice, the impact depends on where the vulnerable host sits in your environment. A single workstation issue may still be serious if it gives an attacker administrative rights that can be used to harvest tokens, tamper with security tooling, or move toward privileged infrastructure. On a server, especially one with sensitive data or remote administration paths, the same flaw can have much larger blast radius.
Because this is an exploited vulnerability, the remediation conversation should be coupled with a hunt for suspicious privilege changes, unexpected admin activity, unusual service creation, and other signs that a local exploit may already have been used. The main objective is to determine not only whether the patch is applied, but whether the system was compromised before the fix.
For exploitability context and broader triage, FIRST EPSS helps teams prioritise vulnerabilities probabilistically, while MITRE ATT&CK Enterprise Matrix is useful for mapping the kind of privilege-escalation follow-on activity that often follows initial access.
What to do when you cannot remediate immediately
If patching is delayed, the priority is to reduce the chance that the flaw can be exercised from an existing foothold. That means tightening who can log on interactively, reducing local administrative exposure, and limiting the systems where a successful local escalation would matter most. The harder it is for an attacker to get code execution on the host, the less usable the vulnerability becomes.
Containment also means checking whether the affected systems are already serving as jump points, management nodes, or privileged endpoints. A local kernel bug on a workstation is one problem; the same issue on an admin workstation, jump box, or server with access to sensitive services is a much more urgent exposure because it can turn a single compromise into a broader incident.
For identity and privilege hardening around this condition, Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide are both relevant because they address the blast-radius problem that makes privilege escalation so damaging in real environments.
Risk and Threat Considerations
This CVE is high-value to attackers because local privilege escalation is a common bridge between initial access and full system control. Once a kernel flaw is exploitable, a low-privilege foothold can become a much more powerful platform for persistence, defense evasion, and lateral movement.
Failure mechanism: An attacker first gains some level of execution or user access, then uses the kernel flaw to raise privileges on the same host, which can let them disable protections, access protected material, or pivot toward higher-value targets.
Impact: The result can include full host compromise, security-tool tampering, credential exposure, and faster spread across the environment if the escalated system has trusted access to other assets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Active exploitation makes host hardening and exposure reduction central. |
| Recommendation — Harden Windows hosts and remove unnecessary privilege paths that make local escalation easier. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is a known exploited vulnerability requiring urgent remediation. |
| AC-6 — Least Privilege | Privilege escalation risk is materially reduced by limiting local and administrative privilege. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-compromise investigation depends on reviewing suspicious privilege and execution activity. | |
| Recommendation — Prioritise rapid remediation and validate that the fix is deployed everywhere in scope. Restrict local and administrative permissions to reduce the impact of a successful escalation. Review audit data for evidence of privilege escalation or post-exploitation activity. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Known exploited vulnerabilities require disciplined vulnerability handling and prioritisation. |
| Recommendation — Track, prioritise, and remediate the vulnerability through formal technical vulnerability management. | ||
Practitioner Guidance
What to verify: Confirm whether any Windows systems in scope are vulnerable and whether they are exposed to untrusted users, remote administration paths, or high-value privilege boundaries. If the answer is yes, treat them as urgent remediation candidates rather than routine backlog items.
What to prioritise: Patch first on endpoints and servers that can unlock further access, such as admin workstations, jump hosts, and systems with privileged session paths. Then verify that monitoring can detect unusual privilege changes and post-exploitation activity on those hosts.
Practitioner takeaway: For an actively exploited kernel privilege escalation, the real question is not only whether the patch is available, but whether the vulnerable host can meaningfully amplify an attacker’s access before you can remediate it.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- Is CVE-2020-0986 (Microsoft Windows Kernel Privilege Escalation) being exploited in the wild?
- Is CVE-2020-1027 (Microsoft Windows Kernel Privilege Escalation) being exploited in the wild?
- Is CVE-2016-3309 (Microsoft Windows Kernel Privilege Escalation) being exploited in the wild?
- Is CVE-2013-5065 (Microsoft Windows Kernel Privilege Escalation) being exploited in the wild?