Yes. CISA added CVE-2024-35250 to its Known Exploited Vulnerabilities catalogue on 16 December 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Kernel-Mode Driver contains an untrusted pointer dereference vulnerability that allows a local attacker to escalate privileges. Any organisation running the affected product should treat remediation as urgent.
What “exploited in the wild” means for this CVE
For CVE-2024-35250, the practical question is not whether the flaw exists, but whether attackers are already using it. CISA’s addition to the Known Exploited Vulnerabilities catalogue means the vulnerability has crossed that threshold, so defenders should treat it as an active threat, not a theoretical exposure. The key issue is exposure to local privilege escalation on Windows systems.
That changes the operational posture immediately. If an attacker already has low-privilege code execution on a host, an untrusted pointer dereference in a kernel-mode driver can become the next step toward full system control. On that basis, validation should focus on whether any endpoints are still reachable, whether mitigation is in place, and whether the environment shows signs of pre-existing compromise.
For a broader triage approach to actively exploited weaknesses, see Zero-Day and Exploited Vulnerabilities Guide, which covers KEV-driven prioritisation, emergency response, and post-patch hunting.
How to confirm exposure and reduce risk fast
The first task is to confirm whether any Windows systems in scope actually run the affected kernel-mode driver path and whether those systems are reachable by untrusted users or exposed to local code execution paths. For an exploitation-in-the-wild issue, asset inventory matters as much as patching speed, because unknown or unmanaged endpoints are the ones most likely to remain vulnerable after the first response wave.
Remediation should follow the vendor advisory and CISA KEV guidance for version-specific fix details. If immediate patching is not possible, reduce the likelihood that an attacker can reach the vulnerable code path by tightening local access, removing unnecessary software, and accelerating maintenance windows for the highest-value hosts. A KEV-listed flaw should not sit in a normal backlog queue.
When exposure is broader than a single host, pair the fix effort with vulnerability prioritisation and exception management. The point is to eliminate time spent debating severity and instead move straight to scope, urgency, and closure evidence.
For a structured prioritisation workflow, the Vulnerability Management Guide is a useful companion for asset scope, KEV triage, exceptions, and remediation verification.
What to check after remediation and before closing the case
Because this is an in-the-wild exploit class, patching alone is not a complete answer if the endpoint may already have been abused. After remediation, validate whether the host showed signs of local privilege escalation, suspicious process creation, unexpected driver loading, or other persistence consistent with post-exploitation activity. The right question is whether the environment stayed clean long enough to trust the fix.
If there is any indication that the affected machine was used as a foothold, treat credential and session review as part of the response. Kernel-level privilege escalation can change the attacker’s options fast, so rotating only the patched system without checking adjacent access paths may leave the real compromise unresolved. Investigate whether the host was used to reach other internal resources, especially where higher-value administrative access was available.
For Windows ecosystems where exploitation can lead to broader credential exposure, the incident pattern is similar to other privilege-escalation and credential-theft cases. The useful lesson is to verify both the patch state and the blast radius, not just the absence of crash symptoms.
If you need a practical model for post-compromise thinking, Cisco Active Directory credentials leak 2025 is a good reminder that privilege escalation incidents often become access-control incidents after the initial flaw is abused.
Risk and Threat Considerations
Active exploitation means this vulnerability is already part of real attacker tradecraft, not just a lab finding. The main risk is privilege escalation from a local foothold, which can turn a limited compromise into full host control and create a launch point for lateral movement or defensive evasion.
Failure mechanism: An attacker with local execution abuses the untrusted pointer dereference in kernel mode to trigger elevated privileges, then uses that position to tamper with the system or extend access beyond the original user boundary.
Impact: The result can include full compromise of the Windows host, loss of trust in endpoint state, and a higher likelihood that credentials, sessions, or adjacent systems were exposed during the attack chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Actively exploited Windows flaws require rapid remediation and verification. |
| SI-4 — System Monitoring | Active exploitation warrants detection of suspicious post-exploit activity and persistence. | |
| Recommendation — Accelerate patching and document verification for the affected Windows systems. Monitor for unusual driver, privilege, and persistence activity after remediation. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed vulnerabilities need prioritised discovery, remediation, and exception handling. |
| CIS-8 — Audit Log Management | Post-exploitation review depends on logs that show privilege escalation and follow-on access. | |
| Recommendation — Prioritise this CVE in your vulnerability workflow until exposure is removed. Retain and review logs needed to confirm or refute exploitation. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | The question hinges on confirming which assets remain vulnerable to the KEV-listed flaw. |
| Recommendation — Identify all affected Windows assets and record their exposure status. | ||
Practitioner Guidance
What to prioritise: Treat any unpatched system as urgent, but prioritise internet-facing, high-value, and privilege-rich endpoints first. If your estate includes shared admin workstations or systems with broad internal reach, those deserve faster treatment than low-value standalone hosts.
What to verify: Confirm the remediation against the vendor advisory, then validate whether the host was used before the fix landed. Look for evidence of local privilege escalation, unusual driver activity, new persistence, and unexpected internal access that would justify follow-on containment.
Practitioner takeaway: For a KEV-listed Windows kernel flaw, “patched” is not enough on its own, the decision point is whether the host was exposed long enough to become an attacker foothold and whether you have ruled that out.
Related resources from NHI Mgmt Group
- CVE-2024-35250 (Microsoft Windows Kernel-Mode Driver Untrusted Pointer Dereference Vulnerability)
- Is CVE-2025-24990 (Microsoft Windows Untrusted Pointer Dereference) being exploited in the wild?
- Is CVE-2024-38107 (Microsoft Windows Power Dependency Coordinator Privilege Escalation) being exploited in the wild?
- Is CVE-2025-24985 (Microsoft Windows Fast FAT File System Driver Integer Overflow) being exploited in the wild?