CISA's required action for CVE-2021-31979 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Windows in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What to do first when CVE-2021-31979 is in scope
Start by confirming where Microsoft Windows is present, because the fix is only useful if the affected systems are actually in your estate and reachable by your patch process. For widely exploited flaws, treat the search for exposure as part of remediation, not as a separate inventory task. Prioritise systems that are internet-facing or easy to reach from untrusted networks.
Use your normal vulnerability management workflow to prioritise exploited vulnerabilities and move this issue ahead of routine maintenance work. That means validating asset scope, finding every instance that needs attention, and applying the vendor security update or documented mitigation as the first-choice response.
When a fix cannot be applied immediately, the practical stopgap is to reduce exposure. In a Windows kernel elevation scenario, that usually means removing internet exposure, segmenting access, or taking the product out of service until the update path is available. Temporary compensating controls matter most when the affected host has broad network reach or supports sensitive administrative functions.
Why this vulnerability should be treated as a post-exploitation risk
CVE-2021-31979 is not just a patching issue, because privilege escalation flaws often become the second step in a compromise chain. Once an attacker has some level of foothold on a Windows system, a kernel elevation bug can convert that foothold into higher privilege, persistence, and broader control over the host. The direct answer already notes that attackers used this flaw in the wild, which raises the priority for both remediation and compromise review.
That is why post-patch verification should include a look back at whether the host showed signs of abnormal execution, unexpected account changes, suspicious services, or log activity consistent with escalation before the update was installed. The point is not only to close the hole, but to determine whether the system was already abused while the flaw was exposed.
For a broader view of how actively exploited weaknesses move through prioritisation, the CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm exploitation status and the urgency of remediation. If you need a wider operational playbook for actively exploited vulnerabilities, use that to shape triage, mitigation, and post-patch hunting.
How to verify the fix and limit residual exposure
After applying the vendor update, verify that the patched build is actually present on every in-scope system and that exceptions are documented rather than assumed. A successful deployment is not just “the patch job ran”, it is “the vulnerable host has been removed from the exposed population.” If you deferred the update on any machine, keep that exception explicit and time-bound.
If you suspect earlier compromise, review host logs, endpoint telemetry, and administrative activity for signs of privilege abuse before the patch window. A privilege escalation flaw can be used to turn a low-value foothold into a full system compromise, so the integrity question is whether the system was only vulnerable, or already leveraged.
Where the vulnerability sat on a system with privileged access paths, make sure any credentials or sessions that could have been exposed are reassessed. In practice, that means checking whether local admin access, service accounts, or remote management sessions on the affected host need rotation or revalidation after remediation.
Risk and Threat Considerations
This type of kernel privilege escalation matters because it can collapse the separation between initial access and full host control. Once that happens, an attacker can often tamper with security tooling, dump sensitive data, or pivot to other systems that trust the compromised machine.
Failure mechanism: An attacker with some execution on the host abuses the kernel flaw to gain elevated privileges, then uses that position to hide, persist, or move laterally before defenders notice.
Impact: The result can be full system compromise, loss of trust in the endpoint, and a need to treat the host as potentially contaminated even after the patch is installed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Patch exploitation risk depends on timely discovery and remediation of vulnerable Windows hosts. |
| Recommendation — Prioritise, patch, and verify exposed Windows assets through continuous vulnerability management. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management Plan | This CVE response hinges on organized patching, exception handling, and verification. |
| Recommendation — Use a vulnerability management plan to track remediation, exceptions, and verification for affected hosts. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is remediated by applying vendor updates and tracking delayed fixes. |
| AU-6 — Audit Review, Analysis, and Reporting | Post-patch log review is needed to detect earlier exploitation of the flaw. | |
| Recommendation — Apply vendor remediation promptly and document any compensating controls until deployment completes. Review audit data after remediation to identify signs of prior exploitation. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | The CVE is a privilege-escalation flaw used by attackers in the wild. |
| Recommendation — Map detections to privilege-escalation behavior and hunt for post-exploitation activity. | ||
Practitioner Guidance
What to prioritise: Patch internet-facing and high-value Windows systems first, then move to internally reachable hosts with administrative reach or sensitive data access. If you cannot patch immediately, reduce exposure before you argue for delay.
What to verify: Confirm the update is installed on every instance, confirm the vulnerable service or product is not still exposed, and confirm logs were reviewed for pre-patch abuse. If a system has no clear verification trail, do not treat it as safely remediated.
Practitioner takeaway: For an exploited Windows kernel flaw, the real decision is not patch versus wait, it is whether the host must be assumed compromised until patching and compromise review are both complete.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2024-38106 (Microsoft Windows Kernel Privilege Escalation)?
- How do you patch or mitigate CVE-2015-6175 (Microsoft Windows Kernel Privilege Escalation)?
- How do you patch or mitigate CVE-2018-8611 (Microsoft Windows Kernel Privilege Escalation)?
- How do you patch or mitigate CVE-2020-1027 (Microsoft Windows Kernel Privilege Escalation)?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org