How to Fix CVE-2020-0638: Improper Link Resolution Before File Access in Microsoft Update Notification Manager

Actively exploited. Listed in the CISA Known Exploited Vulnerabilities catalog since 2022-05-23; federal civilian agencies were required to remediate by 2022-06-13. This is a local elevation-of-privilege flaw: an attacker who already has a low-privileged foothold on the host uses it to gain SYSTEM. Prioritise multi-user machines, RDP/jump hosts, and any box where untrusted code can run.

What is CVE-2020-0638?

CVE-2020-0638 is a local elevation-of-privilege vulnerability in the Update Notification Manager, a component that ships with Windows 10 and Windows Server. Microsoft’s own description is short: “An elevation of privilege vulnerability exists in the way the Update Notification Manager handles files. To exploit this vulnerability, an attacker would first have to gain execution on the victim system.” The internal name is the “Update Notification Manager Elevation of Privilege Vulnerability.”

The flaw is classified as CWE-59: Improper Link Resolution Before File Access (‘Link Following’). A privileged Windows process tied to the Update Notification Manager opens, writes, or deletes a file by a path that a low-privileged user can influence. Because that process does not safely resolve symbolic links, NTFS junctions, or hard links before it touches the file, an attacker who already runs code on the box can plant a link that redirects the privileged file operation to a target the attacker chooses. The privileged process then writes or overwrites a file the attacker could never reach on their own. That is the classic Windows link-following primitive: turn a SYSTEM-level file write into arbitrary code execution as SYSTEM.

This is an elevation of privilege (EoP) bug, not remote code execution and not a denial of service. The CVSS 3.1 vector confirms it: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base score 7.8. AV:L means the attacker must already be on the machine; PR:L means they need a normal user account, not admin; UI:N means no victim interaction is required. The payoff is full confidentiality, integrity, and availability impact, in practice, SYSTEM. That makes it a textbook second-stage tool: malware or a phishing payload lands as a standard user, then chains CVE-2020-0638 to take over the host. CISA’s SSVC scoring marks exploitation as active with a total technical impact, which is why it sits in the KEV catalog.

Am I affected?

There is nothing to “spot” at runtime: a link-following EoP leaves no banner and no error. Exposure is decided entirely by the Windows build number and whether the January 2020 cumulative update is installed. The affected list covers Windows 10 versions 1709, 1803, 1809, 1903 and 1909 across 32-bit, x64 and ARM64, plus Windows Server 2019 and the Server Core installations of Windows Server versions 1803, 1903 and 1909.

Check the build and the patch state directly:

# Confirm the OS version / build this CVE keys on
[System.Environment]::OSVersion.Version
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId      # e.g. 1809, 1903
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR            # update build revision

# Is any update from January 2020 or later installed?
Get-HotFix | Where-Object InstalledOn -ge ([datetime]'2020-01-14') |
    Sort-Object InstalledOn -Descending | Select-Object HotFixID, InstalledOn

If the machine runs one of the affected builds and has no cumulative update dated 14 January 2020 or later, treat it as vulnerable. Because Windows quality updates are cumulative, any single later monthly update already contains this fix, you do not need the exact January KB, only something at or past it. All of these builds are now past end of servicing, so the real-world action for most readers is to move to a supported, fully patched Windows release.

How to fix CVE-2020-0638

There is no separate package and no vendor “version number” to chase. Microsoft fixed this in the 14 January 2020 security update, shipped as the monthly cumulative update for each affected Windows 10 / Windows Server build. Install that update (or any later cumulative update) and reboot. Every command below is native Windows. this is a Windows-only OS component, so there are no Linux or appliance steps that apply.

Apply the cumulative update (PowerShell, run as administrator)

# Option A: native Windows Update agent (no extra modules)
(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
Start-Process "$env:windir\System32\UsoClient.exe" -ArgumentList "StartScan"
Start-Process "$env:windir\System32\UsoClient.exe" -ArgumentList "StartInstall"

# Option B: PSWindowsUpdate, if you manage patching with it
Install-Module PSWindowsUpdate -Force -Scope CurrentUser -ErrorAction SilentlyContinue
Import-Module PSWindowsUpdate
Get-WindowsUpdate -Install -AcceptAll -AutoReboot -Category 'Security Updates'

Offline / WSUS-blocked hosts: install the MSU by hand

For isolated servers or Server Core boxes that cannot reach Windows Update, download the right cumulative update for your exact build from the Microsoft Update Catalog and install it with wusa.exe. Match the build (1809, 1903, etc.) and architecture (x64 / ARM64) to the host.

# Find your build's cumulative update at:
#   https://www.catalog.update.microsoft.com/Search.aspx?q=CVE-2020-0638
# Download the MSU that matches your ReleaseId + architecture, then:
$msu = "$env:USERPROFILE\Downloads\windows10.0-kbXXXXXXX-x64.msu"   # replace with the real KB filename
wusa.exe $msu /quiet /norestart
shutdown.exe /r /t 60 /c "Reboot to finalise CVE-2020-0638 security update"

Full PowerShell remediation script (detect, patch, verify, log)

<#
.SYNOPSIS  Remediates CVE-2020-0638 (Update Notification Manager EoP) on Windows hosts.
.DESCRIPTION
  Records the current build, installs the latest security cumulative update via the
  native Windows Update agent, confirms an update dated 2020-01-14 or later is present,
  and writes a transcript to %ProgramData%\Patching.
#>
$ErrorActionPreference = 'Stop'
$logDir = "$env:ProgramData\Patching"
New-Item -ItemType Directory -Force -Path $logDir | Out-Null
Start-Transcript -Path "$logDir\CVE-2020-0638-$(Get-Date -Format yyyyMMdd-HHmmss).log"

try {
    Write-Host '[1/4] Recording current build'
    $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
    Write-Host "  ReleaseId=$($cv.ReleaseId)  Build=$($cv.CurrentBuild).$($cv.UBR)"

    Write-Host '[2/4] Triggering security update install'
    (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
    Start-Process "$env:windir\System32\UsoClient.exe" -ArgumentList "StartScan"  -Wait
    Start-Process "$env:windir\System32\UsoClient.exe" -ArgumentList "StartInstall" -Wait

    Write-Host '[3/4] Verifying a Jan-2020-or-later update is present'
    $patched = Get-HotFix | Where-Object { $_.InstalledOn -ge [datetime]'2020-01-14' }
    if ($patched) {
        $patched | Sort-Object InstalledOn -Descending | Select-Object HotFixID, InstalledOn | Format-Table
        Write-Host '  CVE-2020-0638: a qualifying cumulative update is installed.'
    } else {
        Write-Warning '  No update dated 2020-01-14 or later found yet. A reboot or manual MSU install may be required.'
    }

    Write-Host '[4/4] Reboot is required to finalise servicing'
    Write-Host '  Run: shutdown.exe /r /t 60   (schedule during your maintenance window)'
    Write-Host 'CVE-2020-0638 remediation step complete'
} catch {
    Write-Error "CVE-2020-0638 remediation FAILED: $_"
    exit 1
} finally {
    Stop-Transcript
}

If you can't patch immediately

There is no registry toggle or firewall rule that neutralises this specific flaw, it is a file-handling bug inside a privileged OS component, reachable by any local user. Network filtering does not help because the attack vector is local (AV:L), not remote. The honest interim controls are about denying the attacker the local foothold the exploit requires:

• Remove standing local-admin rights and enforce least privilege. The exploit needs a low-privileged account already running code; the smaller your attack surface of interactive users, the fewer paths to it.
• Block the initial code execution. Enable Microsoft Defender, application control (WDAC / AppLocker), and attack-surface-reduction rules so commodity malware cannot land the first-stage payload that would chain into this EoP.
• Tighten and monitor multi-user and RDP hosts first. Terminal servers, jump boxes and shared workstations are where an untrusted local user is most likely to exist. Watch for unexpected junction/symlink creation and unusual writes by update-related services.
• Plan the migration. All affected builds are out of support. The durable fix is a supported, patched Windows release; the cumulative update above is the stopgap if you cannot move immediately.

Verify the fix

1. Confirm the build revision moved: re-run (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR after reboot and check that an update dated 2020-01-14 or later shows in Get-HotFix.
2. Re-run an authenticated vulnerability scan (Nessus, Qualys, OpenVAS, or Microsoft Defender Vulnerability Management) against the host. CVE-2020-0638 must no longer be reported.
3. Because this is a KEV-listed, actively exploited EoP, review for prior abuse: look for unexpected SYSTEM-context processes, new local admins, and junction/symlink activity in update-related directories that predates the patch. Treat anything suspicious as a possible compromise: isolate the host, rotate credentials it held, and run IR triage.
4. Record the change in your CMDB and roll any interim least-privilege or application-control hardening into your standard baseline rather than reverting it.

Is CVE-2020-0638 remote code execution?

No. It is a local elevation-of-privilege (EoP) flaw, CWE-59 link following. The CVSS vector is AV:L, so an attacker must already be running code on the machine as a normal user. They use the bug to escalate to SYSTEM. It is dangerous as a second stage after an initial breach, not as a network entry point.

Which version fixes CVE-2020-0638?

Microsoft did not publish a standalone version number. The fix shipped in the 14 January 2020 security update as the monthly cumulative update for each affected Windows 10 and Windows Server build. Because Windows quality updates are cumulative, any update at or after that date already contains the fix. Match the KB to your build in the Microsoft Update Catalog.

Do I need a Linux or appliance fix for this CVE?

No. The Update Notification Manager is a Windows OS component. There are no apt, dnf, or appliance steps for CVE-2020-0638, the entire remediation is a Windows cumulative update plus a reboot.

The affected builds are end of life. What should I do?

Every Windows 10 / Server build listed for this CVE is past end of servicing. Install the January 2020 (or any later) cumulative update if the host still receives updates, but the durable fix is migrating to a currently supported, fully patched Windows release. Unsupported builds accumulate later unpatched flaws regardless of this one.

References

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

This guide was assembled from the official vendor advisory, NVD record, and CISA KEV listing on 2026-05-25. 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-2020-1020: Remote Code Execution in Windows
• How to Fix CVE-2020-17144: Microsoft Exchange Remote Code Execution
• How to Fix CVE-2020-0601: Spoofing in Windows
• How to Fix CVE-2020-0674: Remote Code Execution in Internet Explorer 10
• How to Fix CVE-2020-0796: Buffer overflow in Microsoft Windows