How to Fix CVE-2019-0859: Elevation of Privilege in Windows

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚠️ Patch immediately. CVE-2019-0859 is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03). Federal agencies had until 2022-05-03 to remediate.

What is CVE-2019-0859?

CVE-2019-0859 is an elevation of privilege vulnerability in Win32k, the kernel-mode graphics and windowing subsystem (win32k.sys) that ships with every supported version of Windows. The flaw is the way Win32k handles objects in memory: it can use a kernel object after that object has already been freed, which lets carefully crafted code corrupt kernel memory and run with SYSTEM privileges. Microsoft's own description: "An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory, aka 'Win32k Elevation of Privilege Vulnerability'." Microsoft tracked two sibling Win32k EoP bugs separately the same month, CVE-2019-0685 and CVE-2019-0803. so do not assume one KB closes all three.

This is a local privilege-escalation bug, not remote code execution. The CVSS vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: an attacker already needs the ability to run code on the machine as a low-privileged user. That is exactly how it gets used in real intrusions. Attackers chain a remote entry point (a malicious document, a browser exploit, a phished payload running as a normal user) with a Win32k bug like this one to jump from a sandboxed or limited account to full SYSTEM control. Once an attacker holds SYSTEM, they can install kernel drivers, disable endpoint protection, dump credentials with Mimikatz, and move laterally. In the campaign that exposed this CVE, the privilege escalation was paired with a PowerShell backdoor and used to deliver the Buhtrap banking trojan. CISA has confirmed exploitation in the wild, so this is not a theoretical risk.

Am I affected?

Every supported Windows release at the time was affected: Windows 7 SP1, 8.1, RT 8.1, and Windows 10 (every build from RTM through 1809), plus Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, and 2019, including Server Core installations. If a machine in that list never received the April 2019 (or any later) cumulative update, it is still vulnerable. These OS releases are all out of mainstream support now, so the practical question is usually "is this an old, unpatched box?"

Two checks tell you where you stand. First, confirm your OS build, then list whether the April 2019 (or any newer) cumulative update is installed:

# 1. Identify your Windows build
[System.Environment]::OSVersion.Version
(Get-CimInstance Win32_OperatingSystem).Caption

# 2. List installed updates, newest first.
# If the most recent QualityUpdate predates April 2019, you are exposed.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID, InstalledOn -First 15

# 3. Check the patch level of the vulnerable driver itself
(Get-Item "$env:SystemRoot\System32\win32k.sys").VersionInfo.FileVersion
(Get-Item "$env:SystemRoot\System32\win32kfull.sys" -ErrorAction SilentlyContinue).VersionInfo.FileVersion

There is no registry toggle or feature flag to inspect here: the fix lives in the binary version of win32k.sys / win32kfull.sys, which the cumulative update replaces. If the machine is current on monthly updates, you are already covered.

How to fix CVE-2019-0859

There is exactly one supported fix: install the Microsoft security update that replaces win32k.sys. The fix shipped in the April 2019 Patch Tuesday cumulative update (2019-04-09). There is no standalone patch, no config change, and no workaround that removes the flaw, Win32k cannot be disabled on a normal desktop. Because the relevant KB number differs per OS build, open the MSRC advisory for CVE-2019-0859, find your exact build in the affected-products table, and note the KB it lists for that build. For most environments the simplest correct action is just "get current on monthly cumulative updates," since any cumulative update from May 2019 onward already contains this fix.

Option A. let Windows Update apply the cumulative update

On a single machine, this is the cleanest path. From an elevated PowerShell prompt:

# Trigger an update scan and install via the built-in agent.
# Requires the PSWindowsUpdate module (run once):
Install-Module PSWindowsUpdate -Force -Scope AllUsers
Import-Module PSWindowsUpdate

# Install all pending security/cumulative updates and reboot when done
Get-WindowsUpdate -MicrosoftUpdate -Category 'Security Updates' -AcceptAll -Install -AutoReboot

If you cannot install a third-party module, use the in-box agent directly: UsoClient StartScan then UsoClient StartInstall, or run wuauclt /detectnow /updatenow on the older 2008/7-era hosts.

Option B, install the exact KB offline (.msu)

For air-gapped or tightly change-controlled servers, download the specific KB for your build from the Microsoft Update Catalog and apply it with wusa.exe. Replace the KB number with the one your build's row in the MSRC advisory lists (for example, Windows 7 SP1 / Server 2008 R2 took the April 2019 monthly rollup; Windows 10 builds each took their own cumulative update):

# Run as Administrator. Stage the .msu you downloaded from the Update Catalog.
$msu = "$env:TEMP\windows-cve-2019-0859-fix.msu"   # the file you downloaded for YOUR build
if (-not (Test-Path $msu)) {
    throw "Place the correct .msu for your build at $msu first (see the MSRC advisory for the KB ID)."
}
Start-Process wusa.exe -ArgumentList "`"$msu`" /quiet /norestart" -Wait
Restart-Computer -Force

Option C: push it to a fleet with WSUS / Intune / SCCM

For more than a handful of machines, approve the April 2019 (or any later) cumulative update in WSUS / Configuration Manager, or let Windows Update for Business deploy it through an Intune update ring. Target the security-update classification and let the per-build KB resolve automatically; do not try to hand-pick one KB for a mixed fleet, because Windows 7, 8.1, the various Windows 10 builds, and each Server SKU each get a different package.

If you can't patch immediately

There is no vendor-published workaround that neutralizes this bug, Microsoft's only listed remediation is the security update, and Win32k is a core component you cannot switch off on a desktop. Everything below is defense-in-depth that raises the bar for an attacker who is trying to chain this local EoP after an initial foothold. None of it is a substitute for the patch.

• Remove standing local-admin and tighten least privilege. This is a local EoP: the attacker must already be running code as some user on the box. The fewer interactive logons and the less software running with elevated rights, the smaller the window to land the exploit.
• Block the delivery vector. The real-world campaign delivered this via a malicious document plus a PowerShell backdoor. Enable Microsoft Defender Attack Surface Reduction rules (block Office child processes, block obfuscated scripts), enforce macro restrictions, and turn on Controlled Folder Access.
• Constrain PowerShell. Turn on PowerShell script-block and module logging, and prefer Constrained Language Mode where feasible, so the backdoor stage is harder to run and easier to detect.
• Use an EDR with kernel-exploit detection. Win32k exploitation typically corrupts kernel objects and abuses GDI/window-station primitives; modern endpoint products flag that behavior even when the specific CVE is unknown.

# Example: enable two relevant Defender ASR rules (run as Administrator).
# Block all Office applications from creating child processes:
Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A -AttackSurfaceReductionRules_Actions Enabled
# Block execution of potentially obfuscated scripts:
Add-MpPreference -AttackSurfaceReductionRules_Ids 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC -AttackSurfaceReductionRules_Actions Enabled
# Turn on PowerShell script-block logging via the registry
$p = 'HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item $p -Force | Out-Null
Set-ItemProperty $p -Name EnableScriptBlockLogging -Value 1

How to verify the fix worked

Confirm the specific KB is present, then confirm the driver itself moved forward.

# 1. Confirm the KB from the MSRC advisory is installed (swap in your build's KB ID)
Get-HotFix -Id KBxxxxxxx -ErrorAction SilentlyContinue

# 2. Or just confirm the latest update is from April 2019 or newer
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID, InstalledOn -First 5

# 3. Confirm the patched Win32k binary
(Get-Item "$env:SystemRoot\System32\win32kfull.sys" -ErrorAction SilentlyContinue).VersionInfo.FileVersion
(Get-Item "$env:SystemRoot\System32\win32k.sys").VersionInfo.FileVersion

Expected output: the KB listed in the advisory for your build appears with an InstalledOn date that matches your patch window, and the machine has rebooted so the new win32k.sys is the one actually loaded. A pending-reboot state means the old, vulnerable driver is still in kernel memory. always reboot before you call this fixed.

Then re-run any vulnerability scanner you used previously and confirm the finding for CVE-2019-0859 has cleared. Because this CVE was exploited as a zero-day, sweep affected hosts for compromise as well: look for unexpected SYSTEM-level processes, suspicious PowerShell activity in your script-block logs, and new services or drivers created around the time the box was unpatched.

Frequently asked questions

Can CVE-2019-0859 be exploited remotely?

No. The CVSS attack vector is Local (AV:L), so an attacker must already be able to run code on the machine as some user. Its danger is as the second stage of an attack: it turns a low-privileged foothold (from a phished document or browser exploit) into full SYSTEM control. In the wild it was paired with a PowerShell backdoor to deliver the Buhtrap trojan.

Which KB fixes CVE-2019-0859?

The fix shipped in the April 2019 Patch Tuesday updates (2019-04-09), but the KB number depends on your build, Windows 7 SP1 and Server 2008 R2, the various Windows 10 builds, and each Server SKU each got a different package. Look up your exact build in the MSRC advisory's affected-products table to get the right KB, or simply install any cumulative update from April 2019 onward, which already contains it.

Is there a workaround if I can't patch yet?

No. Microsoft published no workaround, and Win32k cannot be disabled on a normal desktop. The only fix is the security update. Until you patch, reduce risk by removing standing local-admin rights, blocking the document/script delivery vector with Defender ASR rules, and watching for kernel-exploit behavior with an EDR: but treat all of that as temporary.

Do I need to reboot after installing the update?

Yes. The fix replaces the kernel driver win32k.sys / win32kfull.sys, and the old, vulnerable copy stays loaded in memory until the machine restarts. A host showing "pending reboot" is still exploitable, so reboot before you mark it remediated.

References

• Official vendor advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0859
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2019-0859
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Written by Sai Kiran Pandrala on 2026-05-25. Sourced from the official vendor advisory, the NVD record, and the CISA KEV listing. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Other CVEs touching related code paths, worth patching together with this one:

• How to Fix CVE-2019-1429: Remote Code Execution in Internet Explorer 9
• How to Fix CVE-2019-0841: Improper Link Resolution Before File Access in Microsoft Windows
• How to Fix CVE-2019-1064: Improper Link Resolution Before File Access in Microsoft Windows
• How to Fix CVE-2019-0903: Remote Code Execution in Microsoft Graphics Device Interface (GDI)
• How to Fix CVE-2019-0703: Information Disclosure in Microsoft Windows