CVE-2020-0601: Microsoft Windows CryptoAPI Spoofing Vulnerability
Microsoft Windows CryptoAPI (Crypt32.dll) contains a spoofing vulnerability in the way it validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using…
CVE-2020-0601 is a spoofing vulnerability in Microsoft Windows CryptoAPI (Crypt32.dll) that affects how the system validates Elliptic Curve Cryptography (ECC) certificates. It is also known as CurveBall. An attacker who exploits it can present a spoofed code-signing certificate so that a malicious executable appears to come from a trusted source, or can interfere with encrypted connections. Because CryptoAPI underpins certificate checks across Windows, the issue matters to any organization running affected Windows systems that rely on code signing or TLS trust decisions.
Public detail is limited to the vendor and CISA descriptions; confirm exact product editions, builds, and patch identifiers against the Microsoft advisory before acting.
How it works
The weakness is classified as CWE-295 (Improper Certificate Validation). CryptoAPI fails to validate ECC certificates correctly. An attacker can craft a certificate that the vulnerable validation logic accepts as legitimate even though it is not. With a spoofed code-signing certificate, the attacker can sign malware so that Windows treats the file as coming from a trusted publisher. The same flawed validation can also enable man-in-the-middle attacks against connections that depend on ECC certificates, potentially allowing decryption of confidential information on those connections. Specific exploit mechanics beyond this description are not provided in the given facts and must be confirmed against the vendor advisory.
Am I affected? How to find it in your systems
The vulnerability affects Microsoft Windows components that use CryptoAPI (Crypt32.dll) for ECC certificate validation. This library is present on typical Windows client and server installations that perform code-signing checks, TLS, or other certificate-based trust operations.
- Inventory Windows endpoints and servers (workstations, domain controllers, application hosts, and any systems that validate signed binaries or terminate TLS) via your asset management, SCCM/Intune, or vulnerability scanner.
- Identify systems that have not yet received the Microsoft update that addresses CVE-2020-0601; compare installed OS builds and CryptoAPI-related updates against the versions listed in the vendor advisory.
- Review software and processes that rely on ECC certificates for code signing or secure channels; these are the primary exposure points.
- Telemetry signs of possible exploitation are not detailed in the provided facts. In general for this class, watch for unexpected trusted publishers, anomalous signed binaries that fail independent verification, certificate validation errors, or unusual man-in-the-middle indicators on ECC-protected connections. Confirm any detection guidance with Microsoft and your EDR vendor.
How to remediate
Patch first. Apply the updates Microsoft released for this vulnerability exactly as described in the vendor advisory and per CISA’s required action to apply updates per vendor instructions. After patching, verify that Crypt32.dll and related certificate-validation components are at the remediated level on every Windows system in scope.
- Prioritize internet-facing hosts, systems that validate third-party code, and machines used for software distribution or certificate services.
- Reboot if the advisory requires it so the updated CryptoAPI is loaded.
- For hardening beyond the patch: enforce strong code-integrity policies where supported, prefer certificates and algorithms your environment has validated, and limit the set of trusted root and intermediate CAs to those you explicitly manage.
- Retest certificate validation and code-signing workflows after the update to confirm expected behavior.
If you can't patch immediately
Until the vendor update can be deployed, reduce risk with compensating controls suited to improper certificate validation and spoofed code signing.
- Segment high-value systems and restrict outbound connections that could be used for man-in-the-middle attacks against ECC-protected sessions.
- Use application allow-listing or similar controls so only known-good binaries run, reducing reliance on CryptoAPI’s trust decision alone.
- Where a web application firewall or TLS inspection proxy is in use, ensure it does not re-introduce untrusted ECC certificates; prefer terminating and re-encrypting only with certificates you control.
- Increase monitoring for newly appeared trusted publishers, unexpected signed executables, and certificate-related anomalies in security logs and EDR.
- Disable or avoid use of ECC certificate validation paths only if the vendor documents a supported workaround; otherwise do not break required cryptography. Confirm any temporary configuration change against the Microsoft advisory.
If your data may have been exposed
Actively exploited certificate-validation flaws can lead to malware execution or interception of confidential data, which in turn can result in broader compromise. Ransomware use is not documented for this CVE in the provided facts. If you suspect exposure, follow your incident-response process: isolate affected hosts, preserve logs, rotate credentials and certificates that may have been observed, and validate the integrity of signed software. You can also run a free exposure scan of your email addresses against known breach data to see whether associated accounts appear in prior breaches while you complete containment and recovery.
AICompiled with AI assistance from public sources and published under our editorial standards.