CVE-2024-35250: Microsoft Windows Kernel-Mode Driver Untrusted Pointer Dereference Vulnerability

CVE-2024-35250 is an untrusted pointer dereference vulnerability in a Microsoft Windows kernel-mode driver. It allows a local attacker who already has some access on a system to escalate privileges. For IT and security teams, this matters because successful privilege escalation can turn limited footholds into full system control, enabling further lateral movement, persistence, or data access on Windows hosts.

Public detail is limited to the CISA description of the flaw class and impact. Confirm all product, version, and patch specifics against the vendor advisory before acting.

How it works

The weakness is classified as CWE-822: Untrusted Pointer Dereference. In kernel-mode drivers, pointers that originate from or are influenced by less-privileged code must be carefully validated before the kernel uses them. When validation is missing or incomplete, an attacker can supply or influence a pointer value that the driver then dereferences in a privileged context.

A local attacker abuses this by interacting with the affected driver in a way that causes it to treat an attacker-controlled or untrusted pointer as valid. The result is typically elevation of privileges within the Windows kernel, allowing the attacker to perform actions reserved for higher-privilege accounts or the system itself. Exact call paths, IOCTL interfaces, or trigger conditions are not provided in the available facts and must be confirmed against the vendor advisory; do not assume specific exploit mechanics.

Am I affected? How to find it in your systems

The vulnerability affects Microsoft Windows systems that include the vulnerable kernel-mode driver. Kernel-mode drivers are present on essentially all Windows installations, from workstations and servers to virtual machines and cloud instances running Windows.

• Inventory Windows hosts via asset management, configuration management databases, or endpoint detection tools that report OS build and installed drivers.
• Check driver load status and versions using built-in tools such as driverquery, Get-WindowsDriver, or third-party inventory agents that enumerate kernel modules.
• Confirm whether your specific Windows builds and driver versions are listed as affected in the Microsoft advisory; public facts here do not enumerate exact versions.
• Review configurations that load third-party or optional kernel drivers, as the vulnerable component is described as a kernel-mode driver.

Telemetry signs of exploitation are not detailed in the available facts. In general for local privilege-escalation attempts against kernel drivers, look for unusual process activity that interacts with drivers (for example, unexpected DeviceIoControl calls), sudden privilege changes, or anomalous kernel-mode crashes and bugchecks. Correlate with endpoint detection and response (EDR) alerts for privilege escalation. Confirm any specific indicators against the vendor advisory and CISA guidance.

How to remediate

Patch first. Apply the vendor update named in the Microsoft advisory for CVE-2024-35250. CISA’s required action is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.

• Deploy the security update through your standard Windows Update, WSUS, Microsoft Endpoint Configuration Manager, or other patch-management channel as soon as it is validated in your environment.
• Prioritize systems where local user access is common (shared workstations, jump hosts, developer machines) and systems that already face elevated risk.
• After patching, verify the update is installed and that the affected driver has been replaced or mitigated as described by Microsoft.
• For this class of kernel pointer issues, additional hardening includes enabling kernel-mode code integrity features, restricting who can load drivers, and applying least-privilege principles so that local users cannot easily reach the vulnerable interface.

Do not rely on version numbers or build lists that are not present in the vendor advisory; always cross-check.

If you can't patch immediately

Until the vendor update can be applied, reduce the attack surface and increase detection.

• Segment systems so that local access is limited; isolate high-value hosts and restrict interactive logons.
• Disable or unload the affected driver if the vendor documents a safe way to do so and the functionality is not required; confirm this option against the advisory.
• Apply application control and driver signature enforcement policies to limit which code can interact with kernel drivers.
• Use virtual patching or host-based controls where available to block known interaction patterns, while recognizing that kernel-level flaws are harder to mitigate with network WAFs.
• Increase monitoring for local privilege-escalation behaviors: unexpected elevation events, unusual driver IOCTL activity, and new processes running as SYSTEM or with high integrity levels.
• Enforce strong local account hygiene, multi-factor authentication for privileged access, and just-in-time elevation so that an attacker has fewer opportunities to reach the vulnerable code path.

These measures lower risk but do not replace the official patch. Plan to remediate fully as soon as operationally feasible.

If your data may have been exposed

Actively exploited local privilege-escalation vulnerabilities can lead to broader compromise and data exposure once an attacker gains higher privileges. Known ransomware use of this specific CVE is not documented in the available facts. If you suspect exploitation, follow your incident-response process: isolate affected hosts, preserve forensic evidence, reset credentials, and hunt for persistence. You can also run a free exposure scan of your email addresses against known breach data sets to check whether credentials or personal information have already appeared in public dumps, then take appropriate credential-reset and monitoring steps.