CVE-2019-1075: Denial of service in .NET Core

Lede

In May 2019, Microsoft disclosed CVE-2019-1075, a denial-of-service (DoS) vulnerability in .NET Core caused by improper handling of web requests. The flaw allowed a remote, unauthenticated attacker to send a specially crafted request to a .NET Core web application and crash or hang the process, taking the service offline for legitimate users. There was no confidentiality or integrity impact — this was a pure availability bug — but for any team running production APIs, web front-ends, or internal services on the affected runtime, an unauthenticated, network-reachable crash-the-server bug is a serious operational risk.

CVE-2019-1075 is one of several ".NET Core denial of service 2019" advisories Microsoft shipped that year as part of its regular .NET Core, ASP.NET Core, and Entity Framework Core servicing updates, and it's a useful case study in why runtime and framework patching discipline matters just as much as application-level code review.

Affected versions and components

Per Microsoft's advisory, the vulnerability existed in the .NET Core runtime itself, specifically in the request-handling code path used by .NET Core web applications — meaning any ASP.NET Core application hosted on the affected .NET Core versions was potentially exposed, regardless of the application's own code quality. Microsoft's guidance identified the .NET Core 2.1 and 2.2 servicing branches as impacted.

Because the vulnerable code lived in the shared runtime rather than in a NuGet package an application team controlled directly, exposure was determined by which .NET Core runtime version was installed on the host or container image serving traffic — not by anything in the application's own dependency tree. This is a recurring theme in supply-chain risk: the vulnerable component here is the platform, and every service built on top of it inherits the exposure automatically until the underlying runtime is patched.

CVSS, EPSS, and KEV context

Microsoft's advisory and the associated NVD entry categorize CVE-2019-1075 as a network-exploitable, unauthenticated, low-complexity availability issue — consistent with the classic "crafted request causes a crash" DoS pattern (no privileges required, no user interaction, impact limited to availability). Advisories of this shape are typically scored in the High severity range under CVSS v3, reflecting the fact that exploitation requires nothing more than network access and a single malformed request, even though the blast radius is limited to service disruption rather than data compromise.

We did not find evidence that CVE-2019-1075 carries a notably elevated EPSS (Exploit Prediction Scoring System) probability, and it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. That combination — high theoretical severity, but no confirmed record of in-the-wild exploitation — is common for framework-level DoS bugs: they're straightforward to weaponize against a specific, unpatched target, but they don't generate the same mass-exploitation incentive as vulnerabilities that yield remote code execution or data access. That said, absence from KEV should not be read as "safe to ignore" — DoS conditions in widely deployed runtimes remain attractive for opportunistic disruption, and EPSS/KEV status can change as new tooling or proof-of-concept code circulates.

Timeline

• Vulnerability identified and reported to Microsoft through the standard coordinated disclosure process used for .NET Core security issues (specific reporter and initial report date were not publicly disclosed in Microsoft's advisory).
• May 2019 — Microsoft published the advisory for CVE-2019-1075 as part of that month's .NET Core, ASP.NET Core, and Entity Framework Core security update cycle, alongside guidance for affected 2.1 and 2.2 servicing branches.
• Patched runtime and SDK builds released — the .NET team shipped updated runtime and SDK packages for the affected servicing branches, correcting the request-handling logic responsible for the crash condition. Organizations were directed to update to the latest patched build within their 2.1 or 2.2 servicing line rather than a specific point release, since .NET Core servicing at the time followed a rolling patch model within each supported minor version.
• Post-disclosure — as with most .NET Core runtime CVEs, distro maintainers, container base image publishers, and cloud platform teams (Azure App Service, Docker Hub official images, Linux distribution packagers) rolled the fix into their respective .NET Core runtime builds shortly after Microsoft's release.

Remediation steps

1. Identify your .NET Core runtime version. Run dotnet --info on hosts, or inspect the base image tag (mcr.microsoft.com/dotnet/core/aspnet:2.1 or 2.2) used in your Dockerfiles and CI pipelines. Don't assume — teams are often surprised to find production nodes still pinned to an old patch level within a "supported" minor version.
2. Update to the latest patched build in your servicing branch. Apply the current patch level for .NET Core 2.1 or 2.2 (or, preferably, move forward to a still-supported major version — 2.1 and 2.2 have both long since reached end of life and no longer receive security updates at all, which is its own risk independent of this specific CVE).
3. Rebuild and redeploy container images. If your applications run in containers, pinning to a moving base image tag isn't enough — you need to actually rebuild images against the patched runtime layer and redeploy; a stale image with the vulnerable runtime baked in stays vulnerable indefinitely.
4. Patch the SDK on build agents, not just the runtime on production hosts. CI/CD build servers using an affected SDK version can produce artifacts that still bundle vulnerable self-contained runtime binaries if self-contained deployment is used.
5. Validate with a request-handling smoke test. After patching, confirm the update took effect by checking the runtime version reported at startup and reviewing application logs for the crash signature (unexpected worker process restarts under normal traffic) that prompted the original advisory.
6. Put continuous runtime inventory in place. The core lesson from CVE-2019-1075 is that DoS exposure in a shared runtime is invisible from application code review alone — you need visibility into exactly which .NET Core build is running everywhere in your fleet, updated automatically as new hosts and images come online.

How Safeguard Helps

CVE-2019-1075 illustrates a gap that pure application-level security testing can't close: the vulnerability lived in the .NET Core runtime, not in any line of code your team wrote, yet every service built on top of an unpatched runtime inherited the exposure. Catching this class of issue requires continuous, accurate visibility into the actual software composition of every artifact you ship — not a point-in-time audit.

Safeguard's software supply chain security platform is built for exactly this problem:

• Runtime and dependency inventory — Safeguard continuously identifies the .NET Core (and broader framework/runtime) versions embedded across your build artifacts, container images, and deployed services, so a runtime-level CVE like this one is flagged automatically rather than discovered after an incident.
• CVE and EPSS-aware prioritization — rather than drowning teams in every disclosed CVE, Safeguard correlates findings with severity, exploitability signals (including EPSS trends), and KEV status, helping teams focus patching effort on what's actually likely to matter.
• Build-to-deploy traceability — because Safeguard tracks components from build through to production deployment, you can answer "are we still running an affected .NET Core build anywhere?" with evidence, not guesswork, across every service and environment.
• Policy-driven gating — organizations can configure Safeguard to block promotion of artifacts built on end-of-life or vulnerable runtime versions, preventing the next unpatched .NET Core build from ever reaching production in the first place.

Framework and runtime CVEs like CVE-2019-1075 are a reminder that supply chain security isn't only about third-party packages — it extends to the platforms your applications run on. Safeguard helps teams maintain that visibility continuously, so remediation is a routine update rather than an incident response.