How to Fix CVE-2020-0601: Spoofing in Windows

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

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

What is CVE-2020-0601?

CVE-2020-0601, nicknamed CurveBall (and sometimes "Chain of Fools"), is a certificate-validation spoofing flaw in Crypt32.dll, the Windows CryptoAPI library that every application relies on to verify digital signatures and TLS certificates. The bug lives specifically in how CryptoAPI validates certificates that use Elliptic Curve Cryptography (ECC). The official MITRE description: "A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source."

The root cause maps to CWE-295, Improper Certificate Validation. When CryptoAPI checks an ECC certificate, it matches the public key but does not fully validate the curve's generator (base point) parameters. Because an ECC public key is derived from the private key and the generator, an attacker can choose an arbitrary private key and craft a custom generator so the math produces the same public key as a trusted root certificate authority, for example Microsoft's own ECC root. CryptoAPI sees the matching public key, trusts the certificate, and never notices that the generator was forged. The attacker then signs anything with a private key they fully control while Windows reports a valid chain to a trusted root.

This is a spoofing vulnerability, not remote code execution or privilege escalation on its own. But the consequences are severe: a malicious binary can show a legitimate-looking Authenticode signature so it sails past SmartScreen, application allow-lists, and a wary user double-checking the publisher. The same flaw lets an attacker forge TLS server certificates for HTTPS interception, defeating the trust that browsers and other clients place in the chain. That is why the CVSS vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N = 8.1 High: network reach, no privileges required, high confidentiality and integrity impact, but it needs the victim to run the file or connect to the spoofed endpoint (UI:R), and there is no availability impact. The U.S. National Security Agency reported it to Microsoft and published its own advisory, an unusually high-profile origin for a Patch Tuesday item.

Am I affected?

You are affected if the host runs Windows 10 (any build from 1507 through 1909) or Windows Server 2016 / 2019, including Server Core, as listed in the Affected row. Older Windows releases such as 7, 8.1, Server 2008 R2, and Server 2012 R2 do not include the vulnerable CNG ECC validation path and were not patched for this CVE. There is no benign "symptom" you can watch for: a successful CurveBall attack is designed to look completely legitimate. Detection is about confirming your build and patch state, not spotting odd behavior.

Check the OS build and whether the January 2020 (or any later) cumulative update is installed:

# Build number: anything below the January 2020 cumulative for your release is vulnerable
[System.Environment]::OSVersion.Version
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR

# List installed updates, newest first - look for the Jan 2020 or later cumulative
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Microsoft also shipped event-log telemetry in the patch itself. After patching, CryptoAPI logs Event ID 1 in the Application log under source Microsoft-Windows-Audit-CVE whenever it catches a certificate that tries to exploit this flaw. That event is your in-the-wild canary:

# Surface any CurveBall exploitation attempts the patched CryptoAPI has flagged
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Audit-CVE'; Id=1} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

How to fix CVE-2020-0601

There is exactly one fix: install Microsoft's January 14, 2020 cumulative update for your Windows build (or any later cumulative, since they are inclusive). The patch corrects how Crypt32.dll validates ECC certificate parameters so a forged generator no longer passes the trust check. Microsoft does not publish a single "fixed version" number; each affected release got its own KB on the same Patch Tuesday. Confirm the exact KB for your build in the MSRC advisory or the Microsoft Update Catalog. Representative KBs from that release include KB4534273 (Windows 10 1809 / Server 2019), KB4534271 (1803), KB4534293 (1709), KB4534276 (1607 / Server 2016), and KB4528760 (1903 / 1909). This is a Windows OS update only; there is no Linux package, no separate service binary, and no port to firewall.

Option 1: Windows Update (recommended, run as Administrator)

On any internet-connected machine the simplest path is to let Windows Update pull and install the cumulative update:

# Trigger a scan and install via the PSWindowsUpdate module
Install-Module -Name PSWindowsUpdate -Force -Scope CurrentUser
Import-Module PSWindowsUpdate
Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install -AutoReboot

Without the module you can drive Windows Update directly:

# Force an immediate update scan/detection
UsoClient StartScan
# Then install pending updates from Settings > Update & Security, or:
UsoClient StartInstall

Option 2: Install the specific KB offline (air-gapped or WSUS-managed)

For hosts that do not reach Windows Update, download the matching .msu for your build from the Microsoft Update Catalog, stage it, and install with wusa.exe. Replace the KB with the one your MSRC advisory lists for your exact build:

# Example for Windows 10 1809 / Server 2019 - use the KB that matches YOUR build
$kb  = 'KB4534273'
$msu = "$env:TEMP\$kb.msu"
# Download the matching .msu from https://www.catalog.update.microsoft.com  then:
Start-Process -FilePath 'wusa.exe' -ArgumentList "`"$msu`" /quiet /norestart" -Wait
Restart-Computer -Force

Detect, patch, and verify across a fleet (PowerShell)

This script checks whether the host already carries a fixed cumulative, installs pending updates if not, and confirms the CryptoAPI exploitation audit channel is present afterward. There is no config to back up for an OS-level CryptoAPI patch, so verification centers on the update history and the audit event source.

# Vendor advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0601
# Run as Administrator
$ErrorActionPreference = 'Stop'
$log = "$env:ProgramData\Patch-CVE-2020-0601.log"
function Write-Log($msg) { "$(Get-Date -Format s)  $msg" | Tee-Object -FilePath $log -Append }

Write-Log "Starting CVE-2020-0601 (CurveBall) remediation"

# 1. Record current build and last installed update
$build = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion')
Write-Log ("Build {0}.{1}, UBR {2}" -f $build.CurrentBuild, $build.DisplayVersion, $build.UBR)
$last = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
Write-Log "Most recent hotfix: $($last.HotFixID) installed $($last.InstalledOn)"

# 2. Install the latest cumulative update (skip if your fleet uses WSUS/SCCM scheduling)
Install-Module -Name PSWindowsUpdate -Force -Scope CurrentUser -ErrorAction SilentlyContinue
Import-Module PSWindowsUpdate -ErrorAction SilentlyContinue
if (Get-Command Get-WindowsUpdate -ErrorAction SilentlyContinue) {
    Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install -IgnoreReboot
    Write-Log "Cumulative update install attempted"
} else {
    Write-Log "PSWindowsUpdate unavailable; running UsoClient scan instead"
    UsoClient StartScan
}

# 3. Verify the patched CryptoAPI audit provider exists (only present once patched)
$auditProvider = Get-WinEvent -ListProvider 'Microsoft-Windows-Audit-CVE' -ErrorAction SilentlyContinue
if ($auditProvider) {
    Write-Log "SUCCESS: CurveBall audit provider present - CryptoAPI patch is active"
} else {
    Write-Log "WARNING: audit provider not found - update may not be applied yet; reboot and recheck"
    exit 1
}

If you can't patch immediately

Microsoft published no registry workaround or configuration toggle for CurveBall; the cumulative update is the only fix. Because the flaw breaks trust in code-signing and TLS certificate validation rather than exposing a listening service, you cannot block it with a firewall rule on a port. Until you patch, lean on compensating controls that do not depend on certificate trust:

• Enforce application allow-listing by hash or path, not by publisher signature, since the whole point of this flaw is forging a trusted signature. Windows Defender Application Control (WDAC) hash rules and AppLocker file-hash rules are appropriate here.
• Inspect TLS at a patched proxy. A forward proxy or NGFW that does its own chain validation on a patched OS will still reject the forged ECC certificate even if an internal client is vulnerable.
• Hunt with the audit event after patching the most exposed hosts first. Patch internet-facing and high-value systems, then watch Event ID 1 from Microsoft-Windows-Audit-CVE across the estate for real exploitation attempts.

Surface allow-list and audit posture quickly:

# Check whether WDAC / Device Guard code-integrity policy is enforced
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object CodeIntegrityPolicyEnforcementStatus, UsermodeCodeIntegrityPolicyEnforcementStatus

# Pull any CurveBall exploitation events already recorded on patched hosts
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Audit-CVE'; Id=1} -ErrorAction SilentlyContinue |
    Format-List TimeCreated, Message

Verify the fix

Confirm the cumulative update landed and the CryptoAPI patch is active. The KB ID from the advisory should appear in the hotfix list with an install date in your patch window:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
# And confirm the patched-only audit provider is registered:
Get-WinEvent -ListProvider 'Microsoft-Windows-Audit-CVE' -ErrorAction SilentlyContinue

Then re-run whatever vulnerability scanner flagged the host and confirm the CVE-2020-0601 finding has cleared. If the system was internet-reachable during the January 2020 disclosure window, sweep for prior Microsoft-Windows-Audit-CVE Event ID 1 entries and review any unexpected software installs whose Authenticode signatures chained to an ECC certificate during that period.

Frequently asked questions

What does CurveBall actually let an attacker do?

It lets an attacker forge a certificate that Windows trusts. By crafting a custom ECC generator, they produce a certificate whose public key matches a trusted root, so CryptoAPI validates a chain that was never legitimately issued. Practically, that means signing malware with a "valid" Authenticode signature and forging TLS server certificates for HTTPS interception. It does not by itself give code execution or admin rights, which is why it is rated 8.1 High rather than Critical, but it defeats a core trust mechanism that other defenses depend on.

Which Windows versions need patching, and which are safe?

Windows 10 (1507 through 1909) and Windows Server 2016 and 2019, including Server Core, are vulnerable and were patched on January 14, 2020. Windows 7, 8.1, Server 2008 R2, and Server 2012 R2 do not contain the affected CNG ECC validation path and were not patched for this CVE. There is no fixed "version number" to compare; install the January 2020 or any later cumulative update for your build.

How do I confirm the patch is working, not just installed?

After patching, CryptoAPI registers the audit provider Microsoft-Windows-Audit-CVE and logs Event ID 1 in the Application log whenever it rejects a certificate that tries to exploit this flaw. Run Get-WinEvent -ListProvider 'Microsoft-Windows-Audit-CVE'; if it returns the provider, the patched CryptoAPI is active. The presence of that provider is a reliable signal beyond a KB simply showing in the hotfix list.

Can I block CurveBall with a firewall rule until I patch?

No. The flaw breaks certificate trust validation inside Crypt32.dll; it is not a network service on a port, so there is nothing to firewall. The only fix is the cumulative update. As a stopgap, use hash-based application allow-listing (WDAC or AppLocker) rather than publisher-signature rules, and route TLS through a patched inspection proxy that performs its own chain validation.

References

• Official vendor advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2020-0601
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Additional reference: http://packetstormsecurity.com/files/155961/CurveBall-Microsoft-Windows-CryptoAPI-Spoofing-Proof-Of-Concept.html
• Additional reference: http://packetstormsecurity.com/files/155960/CurveBall-Microsoft-Windows-CryptoAPI-Spoofing-Proof-Of-Concept.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 CVEs touching related code paths, worth patching together with this one:

• How to Fix CVE-2020-1147: Remote Code Execution in Microsoft SharePoint Enterprise Server
• How to Fix CVE-2020-0688: Remote Code Execution in Microsoft Exchange Server 2013
• How to Fix CVE-2020-0968: Remote Code Execution in Internet Explorer 9
• How to Fix CVE-2020-1054: Elevation of Privilege in Windows
• How to Fix CVE-2020-0674: Remote Code Execution in Internet Explorer 10