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

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

⚠️ Patch immediately. CVE-2019-0863 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-0863?

CVE-2019-0863 is a local elevation of privilege flaw in Windows Error Reporting (WER), the built-in service (WerSvc and the wermgr.exe process) that collects crash dumps and sends them to Microsoft. Microsoft's own one-line summary is precise: the vulnerability “exists in the way Windows Error Reporting (WER) handles files.” It is tracked publicly as the Windows Error Reporting Elevation of Privilege Vulnerability.

WER runs parts of its work as the highly privileged NT AUTHORITY\SYSTEM account. The bug is an arbitrary file write driven by a race condition: WER manipulates files in a directory a standard user can influence, and an attacker who already has a normal interactive or service account on the machine can win the race and redirect a privileged file operation. The public technique, published by Nabeel Ahmed as “Angry Polar Bear,” abuses a discretionary ACL (DACL) on a WER report file plus an NTFS hard-link / oplock trick to get SYSTEM to overwrite or create a file the attacker controls. The end result is code execution as SYSTEM.

This is not remote code execution. The CVSS vector confirms it: AV:L (local), PR:L (the attacker needs an existing low-privilege foothold), UI:N (no user interaction). It is the kind of bug used in the second stage of an intrusion. after phishing, a malicious document, or a web exploit has already landed an unprivileged process. The attacker then chains CVE-2019-0863 to jump from that limited foothold to full administrator. That is exactly why it sits in CISA's KEV catalog: real intrusion crews use WER-style local EoP bugs to take over the host.

The MITRE record assigns the CWE as “not enough information,” but functionally this is an arbitrary file write to elevation of privilege (the CWE-269 / CWE-367 race-condition family). The practical takeaway does not change: a non-admin user on the box can become SYSTEM.

Am I affected?

You are affected if the host runs any unpatched build from the Affected row above and the May 2019 security update is not installed. Because Windows Error Reporting ships in every supported Windows and Windows Server SKU of that era, the exposure is broad, desktops, laptops, RDS session hosts, and servers all qualify. Confirm your build and your installed updates from an elevated PowerShell prompt:

# Show OS build so you can match it to the MSRC advisory
[System.Environment]::OSVersion.Version
(Get-CimInstance Win32_OperatingSystem).Caption

# Confirm the Windows Error Reporting service is present (it is, on affected builds)
Get-Service WerSvc

# List recently installed security updates / hotfixes
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15

The fix is delivered as a cumulative or monthly rollup update, not a standalone hotfix with a single universal KB number: each Windows build has its own KB. Match your build from the first command against the “Security Updates” table in the MSRC advisory to find the exact KB you need.

How to fix CVE-2019-0863

There is one real fix: install the May 2019 (14 May 2019 Patch Tuesday) Windows security update for your build. Microsoft did not publish a registry or configuration workaround for this CVE, patching is the only documented remediation. The update modifies WER's file-handling so the privileged operation can no longer be hijacked.

Windows Update (the normal path)

On a machine that pulls from Windows Update or WSUS, the simplest fix is to install all pending updates and reboot. From an elevated PowerShell prompt:

# Trigger a scan + install via the built-in agent, then reboot when the queue is clear
# (no third-party modules required)
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result   = $searcher.Search("IsInstalled=0 and Type='Software'")
$result.Updates | Select-Object Title, @{n='KB';e={$_.KBArticleIDs}}

# Or simply let Windows Update apply everything and restart:
#   Settings > Update & Security > Windows Update > Check for updates
Restart-Computer -Force

Install the specific KB manually (offline / WSUS-gapped hosts)

For air-gapped or tightly managed servers, download the exact KB for your build from the Microsoft Update Catalog and install the .msu with wusa.exe. Replace KBxxxxxxx with the KB number the MSRC advisory lists for your OS build (for example, the May 2019 rollups KB4499164 / KB4499165 / KB4494441 / KB4499151 and the parallel server KBs. always confirm against the advisory for your specific build).

# 1. On an internet-connected host, search the catalog for your build's May 2019 update:
#    https://www.catalog.update.microsoft.com/Search.aspx?q=KBxxxxxxx
# 2. Copy the downloaded .msu to the target machine, then install it elevated:
$msu = "C:\Patches\windows10.0-kbXXXXXXX-x64.msu"
Start-Process -FilePath 'wusa.exe' -ArgumentList "`"$msu`" /quiet /norestart" -Wait
Restart-Computer -Force

PowerShell script (Windows), detect, install, verify, log

This runnable script checks whether the expected KB is already present, installs the staged .msu if not, reboots, and verifies. Set $expectedKB to the KB the MSRC advisory lists for your build before running.

# Vendor advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0863
# Run as Administrator
$ErrorActionPreference = 'Stop'
$expectedKB = 'KBXXXXXXX'                 # <-- set to the KB for YOUR build from the MSRC advisory
$msuPath    = 'C:\Patches\update.msu'      # <-- staged .msu for that KB
$log = "$env:ProgramData\CVE-2019-0863-remediation.log"
function Write-Log($m){ "$(Get-Date -Format s)  $m" | Tee-Object -FilePath $log -Append }

Write-Log "Remediating CVE-2019-0863 (WER EoP) on $env:COMPUTERNAME"
Write-Log ("OS build: " + [System.Environment]::OSVersion.Version)

# 1. Detect: is the fixing KB already installed?
if (Get-HotFix -Id $expectedKB -ErrorAction SilentlyContinue) {
    Write-Log "$expectedKB already installed; host is patched. Nothing to do."
    return
}

# 2. Install the staged update
if (-not (Test-Path $msuPath)) {
    throw "Update not found at $msuPath. Download $expectedKB from the Microsoft Update Catalog first."
}
Write-Log "Installing $expectedKB from $msuPath"
Start-Process -FilePath 'wusa.exe' -ArgumentList "`"$msuPath`" /quiet /norestart" -Wait

# 3. Reboot is required for the WER fix to take effect
Write-Log "Install finished; rebooting to apply."
Restart-Computer -Force
# --- after reboot, re-run the verify block below ---

# 4. Verify (run after the reboot)
if (Get-HotFix -Id $expectedKB -ErrorAction SilentlyContinue) {
    Write-Log "SUCCESS: $expectedKB present. CVE-2019-0863 remediated."
} else {
    Write-Log "FAILURE: $expectedKB still missing after install."
    exit 1
}

If you can't patch immediately

Microsoft published no supported workaround for CVE-2019-0863: there is no kill-bit, no registry toggle, and no firewall rule that closes it, because the attack is entirely local and uses a legitimate built-in service. Anyone selling you a “mitigation” that blocks a network port is wrong: this bug has no network surface (AV:L). The only real levers if you genuinely cannot patch in the same maintenance window are defense-in-depth measures that raise the bar for the foothold the attacker needs first:

• Deny the foothold. Because the attacker must already run code as a low-privileged user, removing local logon rights and standing local-admin sprawl shrinks who can even attempt the chain. Audit interactive and service accounts on the host.
• Disabling WER is not a clean mitigation. You can stop the service (Stop-Service WerSvc; Set-Service WerSvc -StartupType Disabled), but Windows components restart and use WER on demand, so this does not reliably close the bug and it breaks crash diagnostics. Treat it as a last resort, not a fix.
• Watch for the technique. The public exploit drops and renames files in WER's report queue under %ProgramData%\Microsoft\Windows\WER\ and abuses hard links. Enable file-system auditing and EDR detections for unexpected hard-link creation and writes by wermgr.exe into attacker-writable paths.

None of these replace the May 2019 update. Patch on an emergency timeline; this CVE is on the CISA KEV list precisely because attackers use it.

Verifying the fix

After the update installs and the machine reboots, confirm the fixing KB is present and that the WER service is running normally:

# Confirm the specific KB for your build is installed (use the KB from the MSRC advisory)
Get-HotFix -Id 'KBXXXXXXX'

# Or review the most recent updates and match the InstalledOn date to your patch window
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

# WER should still be present and healthy after patching
Get-Service WerSvc

Then re-run whatever vulnerability scanner flagged the host (Nessus, Qualys, Defender for Endpoint, etc.) and confirm the CVE-2019-0863 finding has cleared. If the host was an internet-facing terminal server or a machine that took an unprivileged compromise during the exposure window, treat patching as necessary but not sufficient: hunt for new local accounts, scheduled tasks, and services created as SYSTEM, and review WER report-queue activity for the hard-link technique described above.

Frequently asked questions

Can CVE-2019-0863 be exploited remotely?

No. The CVSS vector is AV:L (local) with PR:L, meaning the attacker must already be able to run code on the machine as a low-privileged user. It is a privilege-escalation bug used after an initial foothold, not a remote entry point. There is no network port to firewall off.

What does CVE-2019-0863 actually let an attacker do?

Windows Error Reporting performs file operations as SYSTEM, and a race condition in how it handles those files lets a non-admin user redirect a privileged write. The public “Angry Polar Bear” exploit chains a DACL and an NTFS hard link to get SYSTEM to write attacker-controlled content, yielding full SYSTEM-level code execution on the host.

What is the fix and where do I get the KB?

Install the May 2019 (14 May 2019) Windows security update for your build. There is no single universal KB, each Windows and Windows Server build has its own. Match your OS build against the Security Updates table in the MSRC advisory for CVE-2019-0863 to find the exact KB, then deploy via Windows Update, WSUS, or the Microsoft Update Catalog.

Is there a workaround if I can't patch this week?

No supported workaround exists. Microsoft documented patching as the only remediation. You can reduce risk by tightening who can run code on the host and by auditing WER report-queue activity, but disabling the WER service is unreliable and breaks crash diagnostics. Given its place on the CISA KEV list, treat this as an emergency patch.

References

• Official vendor advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0863
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2019-0863
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Additional reference: http://packetstormsecurity.com/files/153008/Angry-Polar-Bear-2-Microsoft-Windows-Error-Reporting-Local-Privilege-Escalation.html

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 defects in the same area that deserve attention during this patch cycle:

• How to Fix CVE-2019-1253: Improper Link Resolution Before File Access in Microsoft Windows
• How to Fix CVE-2019-0676: Information Disclosure in Microsoft Internet Explorer
• How to Fix CVE-2019-1130: Improper Link Resolution Before File Access in Microsoft Windows
• How to Fix CVE-2019-0803: Elevation of Privilege in Windows
• How to Fix CVE-2019-1429: Remote Code Execution in Internet Explorer 9