On January 14, 2020, as part of that month's Patch Tuesday release, Microsoft disclosed CVE-2020-0602, a denial of service vulnerability in ASP.NET Core. The advisory describes the flaw simply: ASP.NET Core improperly handles certain web requests, and an unauthenticated remote attacker who sends a specially crafted request can drive the affected application into a denial of service condition. No data is disclosed and nothing is tampered with — the impact is purely availability. That makes it an easy bug to underestimate, but for any team running customer-facing ASP.NET Core services, a remotely triggerable, no-auth-required crash or hang is still a serious operational risk, especially when it can be automated and repeated against production endpoints.
CVE-2020-0602 did not arrive alone. Microsoft shipped it alongside a closely related sibling, CVE-2020-0603, another ASP.NET Core denial of service issue patched the same day through a different code path in the request-handling pipeline. The same Patch Tuesday also included the much more widely publicized CVE-2020-0601, the Windows CryptoAPI spoofing vulnerability ("CurveBall") reported by the NSA. It's worth being precise here: CVE-2020-0601 is a completely separate component (the Windows crypto stack) and vulnerability class (certificate validation spoofing). CVE-2020-0602 is unrelated to it beyond sharing a release date, and conflating the two in asset inventories or ticket triage is a common mistake worth avoiding.
Affected versions and components
Microsoft's advisory scopes CVE-2020-0602 to the ASP.NET Core web framework, specifically the 3.0 and 3.1 release lines of ASP.NET Core and the corresponding .NET Core 3.0 and 3.1 runtimes and SDKs. The vulnerable code sits in how the Kestrel-hosted request pipeline parses and processes inbound HTTP requests, which is why the fix was distributed through the same channels used for routine .NET Core servicing: updated .NET Core SDK and runtime installers, updated NuGet packages for the ASP.NET Core shared framework, and — for Windows Server deployments using the .NET Core hosting bundle with IIS — a Windows Update-delivered component refresh.
Because the vulnerability lives in the framework and runtime layer rather than in application code, exposure isn't limited to any particular kind of app. Any service built on the affected ASP.NET Core versions — APIs, MVC applications, Razor Pages sites, SignalR endpoints — inherited the exposure regardless of what the application itself does with incoming requests. This is a useful reminder that supply chain risk in the .NET ecosystem isn't confined to third-party NuGet packages; the base framework and shared runtime are themselves a dependency that every ASP.NET Core application implicitly trusts.
CVSS, EPSS, and KEV context
NVD's scoring for CVE-2020-0602 reflects a network-exploitable, unauthenticated, no-user-interaction denial of service with no confidentiality or integrity impact and a high availability impact — consistent with a CVSS Base Score in the high range (commonly recorded as 7.5). That scoring profile lines up with what the advisory text describes: an attacker needs no special access or victim interaction, only the ability to reach the vulnerable endpoint over the network, to knock the service offline or degrade it.
On exploitation likelihood, we're not aware of credible public reporting of active, widespread exploitation of CVE-2020-0602 in the wild, and it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. EPSS scoring for a six-year-old, long-since-patched framework vulnerability like this one is generally low, reflecting the absence of observed exploitation activity and the fact that the vulnerable population has largely aged out as organizations moved off unpatched .NET Core 3.0/3.1 builds. That said, low EPSS and absence from KEV describe current opportunistic risk, not historical severity — organizations that never applied the January 2020 servicing update, or that still run unpatched legacy .NET Core 3.0/3.1 instances (for example, in long-lived internal tools, appliances, or vendor-supplied software that embeds an old runtime), remain exposed to a low-complexity, unauthenticated DoS.
Timeline
- January 14, 2020 — Microsoft publishes the security advisory for CVE-2020-0602 and ships the fix as part of the January 2020 Patch Tuesday cycle, alongside the related CVE-2020-0603.
- January 14, 2020 — Updated .NET Core 3.0 and 3.1 SDK/runtime packages, updated ASP.NET Core shared framework NuGet packages, and an updated .NET Core hosting bundle become available through Microsoft's standard distribution channels (the .NET download site, NuGet, and Windows Update for IIS-hosted deployments).
- Post-disclosure — The CVE is indexed in NVD with a CVSS v3 vector reflecting network attack vector, low complexity, no privileges required, no user interaction, and high availability impact. No subsequent KEV listing or widely reported in-the-wild campaign targeting this specific CVE has been documented.
Because Microsoft addressed CVE-2020-0602 as part of routine coordinated disclosure and shipped the fix simultaneously with the advisory, there was no meaningful public exposure window between disclosure and patch availability — the risk window for any given organization is entirely a function of how quickly it applied the January 2020 .NET Core servicing update, not a gap in Microsoft's own response.
Remediation steps
- Identify affected instances. Inventory every host, container image, and deployed artifact running ASP.NET Core 3.0 or 3.1. Pay particular attention to build agents, staging environments, and any third-party or vendor software that bundles its own .NET Core runtime — these are the places patched frameworks most often go unnoticed.
- Apply the January 2020 servicing update. Update the .NET Core SDK and runtime to the patched 3.0.x and 3.1.x servicing releases issued in January 2020, and update any referenced ASP.NET Core shared framework NuGet packages to match. For IIS-hosted applications using the ASP.NET Core Module, update the .NET Core Windows hosting bundle as well.
- Rebuild and redeploy, don't just patch the host. Self-contained deployments and container images bundle the runtime inside the artifact. Patching the underlying OS or installing an updated SDK on the build machine does nothing for an already-built self-contained binary or an already-pushed container image — those need to be rebuilt against the patched runtime and redeployed.
- Verify runtime versions in production, not just in source control or CI configuration. Confirm the actual deployed
Microsoft.AspNetCore.AppandMicrosoft.NETCore.Appshared framework versions on running instances, since a pinned SDK version in a project file doesn't guarantee the deployed environment picked up the matching patched runtime. - Check downstream and vendored software. Any internally maintained tool, appliance, or third-party product built on ASP.NET Core 3.0/3.1 needs the same verification. Supply chain exposure here often hides in software your team didn't build but does operate.
- Confirm with monitoring and testing, not assumption. After remediation, validate that the patched instances reflect updated shared framework versions and that no unpatched replicas remain in autoscaling groups, blue/green environments, or disaster-recovery images.
Given how long ago this CVE was patched, most currently supported ASP.NET Core deployments (3.1 is long out of mainstream support in favor of newer LTS releases like .NET 6 and .NET 8) will already have moved past the vulnerable versions entirely. The residual risk today is concentrated in legacy systems that were never upgraded off .NET Core 3.0/3.1 at all, which is arguably a bigger problem than CVE-2020-0602 itself: an unsupported runtime carries every subsequent unpatched vulnerability in that line, not just this one.
How Safeguard Helps
CVE-2020-0602 is a good illustration of why framework and runtime versions belong in the same visibility layer as application dependencies. It's not a package you npm install or reference by name in application code — it's the ground floor every ASP.NET Core app is built on, which means it's easy for an SBOM process focused on top-level dependencies to miss it entirely, especially inside self-contained deployments and vendor-supplied binaries where the runtime is baked into the artifact rather than declared in a manifest.
Safeguard's software supply chain platform is built to close exactly that gap. Continuous SBOM generation across build artifacts, container images, and deployed workloads surfaces the actual .NET Core / ASP.NET Core runtime and shared framework versions in use — not just what a project file claims, but what shipped. That inventory is checked against known vulnerabilities like CVE-2020-0602 and CVE-2020-0603, so a legacy .NET Core 3.0 or 3.1 instance sitting in a rarely-touched service, an old container image still referenced by a deployment manifest, or a vendor appliance bundling an outdated runtime gets flagged rather than discovered after the fact.
Because Safeguard tracks provenance from build through deployment, it can also tell you which specific artifacts and environments are still running an unpatched runtime, so remediation teams aren't left guessing which of dozens of services actually need a rebuild. And because EPSS and KEV context change over time, Safeguard continuously reevaluates prioritization rather than relying on a one-time severity rating — so if exploitation activity around older .NET Core denial of service issues were ever to change, the organizations already tracking their runtime inventory through Safeguard would see that shift reflected in their risk queue immediately, rather than needing to rediscover their own exposure from scratch.