CISA's required action for CVE-2018-8406 is to apply updates per vendor instructions. In practice, find every instance of Microsoft DirectX Graphics Kernel (DXGKRNL) 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 patching CVE-2018-8406 should actually look like in an estate
Because CISA directs you to apply vendor updates, the practical first step is to identify every Windows system that includes Microsoft DirectX Graphics Kernel and treat it as a patchable exposure, not a one-off workstation issue. Use asset inventory, endpoint management, and vulnerability scanning to confirm where the component exists, then verify the update actually landed rather than assuming a successful deployment from the change ticket alone.
Vulnerability Management Guide is useful here because this is a prioritisation and verification problem as much as a patching problem: the control objective is to close the exposure, prove it closed, and track exceptions that still need treatment.
When vendor remediation is available, apply it in the normal emergency-patch path, but use the vulnerability as a trigger to reassess the surrounding asset. If the system is hard to patch, inherited, or business-critical, the mitigation path should shift from "wait for a convenient maintenance window" to containment, temporary exposure reduction, and accelerated retirement planning.
How to handle the systems that cannot be patched immediately
If you cannot apply the update right away, reduce the reachable attack surface. The direct answer already calls out two practical options: remove internet exposure or take the product out of service. That means placing the affected host behind stronger network restrictions, removing unnecessary remote access paths, and avoiding any assumption that a non-patched, externally reachable system is an acceptable short-term state.
CISA Known Exploited Vulnerabilities Catalog matters because KEV-listed issues should be treated as active risk, not theoretical weakness. For operational decisions, that usually means exposure reduction first, then patching, then validation, with any exception owned as a time-bound risk decision rather than a permanent workaround.
In practice, the best mitigation when patching lags is to narrow who and what can reach the system, especially from untrusted networks. If the host has no business being internet-facing, moving it behind segmentation or disabling access entirely is often the most defensible interim step until the update can be applied and verified.
How to check for compromise after patching
Patch installation does not tell you whether the flaw was already used. Since this CVE was exploited in the wild, you need to review logs and endpoint telemetry for signs of suspicious activity around the vulnerable period, especially on systems that were exposed externally or were slow to patch. Focus on authentication anomalies, privilege changes, unexpected process activity, and any signs that the host behaved differently before the update was applied.
MITRE ATT&CK Enterprise Matrix helps with that review because privilege escalation rarely appears as a single event. Look for adjacent techniques such as execution, credential access, lateral movement, and persistence, then decide whether the host only needed remediation or whether it also needs incident response and reimaging.
If you find evidence of earlier exploitation, treat the patch as only one part of the fix. Preserve relevant logs, scope adjacent systems that may share trust relationships, and confirm whether the attacker could have used the escalation path to reach higher-value accounts or sensitive data.
Risk and Threat Considerations
Privilege-escalation flaws become much more serious when the vulnerable component sits on an exposed or widely deployed system. The main risk is not just local elevation, but what that elevation unlocks next: tampering, credential access, persistence, and movement toward more privileged control of the endpoint or adjacent systems.
Failure mechanism: An attacker with a foothold can chain the kernel flaw into elevated execution on a host that was already reachable, which turns a single compromise into a much higher-impact breach path.
Impact: The result can be full host compromise, broader trust abuse, and a need for incident response beyond routine patching, especially if the system handled sensitive sessions or was used as a launch point for other activity.
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 | CVE patching and exposure reduction are core continuous vulnerability management concerns. |
| Recommendation — Prioritise, remediate, and verify exploited vulnerabilities on exposed assets first. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The question centers on patching, mitigation, and validation of a known exploited vulnerability. |
| Recommendation — Use vulnerability management processes to track, remediate, and confirm closure of the issue. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE response requires applying vendor updates and documenting mitigation when patching is delayed. |
| Recommendation — Apply vendor fixes promptly and track exceptions until remediation is complete. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | The vulnerability is a privilege-escalation path, so ATT&CK helps frame follow-on abuse and hunting. |
| Recommendation — Map the exploit path to privilege-escalation techniques and hunt for adjacent attacker activity. | ||
Practitioner Guidance
What to prioritise: Patch exposed or internet-reachable instances first, then move inward to internally reachable systems with weaker segmentation. For a KEV-listed privilege escalation, exposure and ease of reach matter more than convenience-based patch order.
What to verify: Confirm the update actually changed the vulnerable state, not just that a deployment job ran. Validate with inventory, scanning, and a post-change review of the affected host group.
Decision rule: If patching must wait, reduce exposure immediately, and if the host cannot be contained to an acceptable level, remove it from service until it can be remediated safely.
Practitioner takeaway: Treat this as both a remediation task and a compromise-assessment task, because the right question is not only whether the patch is installed, but whether the vulnerable system was already used as an entry point.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- How do you patch or mitigate CVE-2018-8611 (Microsoft Windows Kernel Privilege Escalation)?
- CVE-2018-8406 (Microsoft DirectX Graphics Kernel Privilege Escalation)
- 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)?
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