CVE-2019-0815: Remote code execution in .NET Core

Microsoft's Security Response Center (MSRC) assigned CVE-2019-0815 to a remote code execution (RCE) vulnerability affecting .NET Core, disclosed as part of Microsoft's 2019 security update program. Like the majority of Microsoft's RCE advisories, the core risk statement follows the vendor's standard language for this vulnerability class: an attacker who successfully exploited the flaw could execute arbitrary code in the context of the current user. For a runtime as widely embedded as .NET Core — powering everything from internal line-of-business APIs to public-facing ASP.NET Core services and containerized microservices — an unauthenticated or low-privilege RCE in the runtime itself is a serious finding, because it threatens every application built on top of it rather than a single product.

This post walks through what is reliably known about CVE-2019-0815, why runtime-level .NET Core vulnerabilities are disproportionately dangerous from a software supply chain perspective, and what remediation and detection steps organizations should have in place — whether they are patching this specific CVE today on a legacy estate or building processes to catch the next one faster.

A note on sourcing: MSRC advisories for runtime CVEs like this one are frequently thin on public technical detail — Microsoft withholds exploit specifics to reduce weaponization risk, and third-party writeups for lower-profile .NET Core CVEs from this era are sparse compared to headline vulnerabilities like Log4Shell or the SolarWinds incident. Where a specific number, date, or score is not reliably confirmable in the public record, we say so explicitly rather than fill the gap.

Affected Versions and Components

CVE-2019-0815 is scoped to the .NET Core runtime rather than the .NET Framework (the legacy, Windows-only predecessor) or ASP.NET Core as a separate product line, though the two are frequently confused in vulnerability trackers because they share code paths and are patched through overlapping update channels. Organizations working through this CVE, or auditing for it retroactively, should treat the following as the practical scope of investigation:

• .NET Core runtime installations on Windows, Linux, and macOS hosts — .NET Core's cross-platform nature means this is not a Windows-only issue the way many MSRC advisories are.
• .NET Core SDK installations used in build and CI/CD pipelines, since SDK versions bundle a matching runtime.
• Self-contained deployments of .NET Core applications, which embed a specific runtime version inside the application's own deployment artifact rather than relying on a shared, centrally-updated runtime on the host. These are the deployments most likely to be missed during a routine "patch the server" pass, because the vulnerable runtime binaries live inside application directories rather than in a system-wide package.
• Container images built on mcr.microsoft.com/dotnet/core base images tagged to an affected release line, which will silently carry the vulnerable runtime forward into every downstream image build until the base image is bumped and the dependent images are rebuilt.

Because we are not able to confirm the exact minor version boundaries Microsoft cited in the original advisory, any team assessing exposure to CVE-2019-0815 today should cross-reference their installed runtime and SDK versions directly against the authoritative NVD entry and the corresponding .NET Core release notes rather than relying on secondary summaries, including this one.

CVSS, EPSS, and KEV Context

Public CVSS scoring for CVE-2019-0815 is not consistently reproduced across secondary vulnerability databases, and we are not confident enough in any single figure to publish it here as authoritative — readers making risk-acceptance or prioritization decisions should pull the current CVSS vector directly from NVD or MSRC rather than trust a secondhand number. As a general pattern, MSRC-rated .NET RCE vulnerabilities from this period were typically scored in the High to Critical range under CVSS v3, reflecting the "arbitrary code execution" impact statement, but the exact base score and vector string for this specific CVE should be verified at the source before it's used in a compliance or SLA context.

On exploitation likelihood: we found no evidence that CVE-2019-0815 carries an unusually high EPSS (Exploit Prediction Scoring System) score relative to other seven-year-old, low-profile runtime CVEs, and — as of this writing — it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, which tracks vulnerabilities with confirmed evidence of active exploitation in the wild. Absence from KEV is not a guarantee of safety; it primarily means no widely reported exploitation campaign has been publicly attributed to this specific CVE, not that exploitation is impossible. Legacy, unpatched .NET Core installations remain a viable target regardless of a CVE's public profile, particularly where the runtime is exposed on internet-facing services.

Disclosure Timeline

• 2019 — Microsoft discloses CVE-2019-0815 through MSRC as part of its regular monthly security update cadence, alongside a batch of other .NET Framework and .NET Core CVEs typical of that year's Patch Tuesday releases.
• 2019 — A patched .NET Core runtime and SDK are made available through Microsoft's standard distribution channels (Windows Update, the .NET Core download page, and Linux package repositories).
• 2019–present — The CVE is indexed in NVD and mirrored across third-party vulnerability databases and SCA (software composition analysis) tooling, where it continues to surface today in scans of legacy applications and container images that were built from stale base images and never rebuilt.

We are intentionally not asserting a specific month or day for disclosure, since we cannot confirm one with confidence; teams needing an exact date for compliance recordkeeping should pull it directly from the NVD entry or the original MSRC advisory.

Remediation Steps

Regardless of the exact technical root cause, remediation for a runtime-level .NET Core RCE follows a consistent playbook:

1. Identify every runtime and SDK installation in scope. Inventory shared runtimes on hosts, SDK versions in build agents, and — critically — self-contained application deployments and container base images, since these are the locations most likely to be running a stale, embedded copy of the runtime long after the shared host runtime has been patched.
2. Upgrade to a supported, patched .NET Core release line. .NET Core 1.x and 2.x are long out of support; if your estate still contains applications on these lines, the sustainable fix is migrating to a supported .NET / .NET Core release rather than chasing individual CVE patches on end-of-life runtimes.
3. Rebuild and redeploy, don't just patch the host. Updating the shared runtime on a server does nothing for self-contained deployments or container images built against the vulnerable runtime — those artifacts need to be rebuilt from an updated base image and redeployed.
4. Update CI/CD build agents' SDK versions, so that new builds stop reintroducing the vulnerable runtime into fresh deployment artifacts.
5. Re-scan after remediation. Confirm the fix with an SCA or vulnerability scanner that reads actual runtime binary versions inside deployed artifacts and container layers, not just the host OS package manager — this is where stale, embedded runtimes most often hide.
6. Verify against the authoritative advisory. Before closing out a ticket or attesting compliance for CVE-2019-0815 specifically, confirm the fixed version numbers against the current NVD/MSRC record for your exact runtime line.

How Safeguard Helps

CVE-2019-0815 is a useful illustration of a problem that outlives any single patch cycle: runtime and dependency versions drift silently into container images, self-contained deployments, and forked build pipelines, and they stay there — vulnerable — long after the "official" fix has shipped. Point-in-time patching closes the vulnerability on the host you remembered to check; it does nothing for the eleven other places the same vulnerable runtime got baked into an artifact.

Safeguard is built to close that gap continuously rather than reactively. Our software composition analysis inspects actual deployed artifacts — container images, build outputs, and self-contained application bundles — down to the runtime and package version level, rather than trusting host-level package managers that miss embedded copies. That means a stale .NET Core runtime sitting inside a container image built eighteen months ago surfaces in the same scan as your actively-maintained production services, instead of sitting silently outside the visibility of a traditional host-based scanner.

Because Safeguard maintains a continuously updated view of CVE, KEV, and EPSS data alongside your live software inventory, teams can move past manually tracking individual advisories like this one and instead get prioritized, evidence-backed remediation guidance the moment a runtime or dependency in their environment is affected by a newly disclosed — or newly rediscovered — vulnerability. For CVEs like CVE-2019-0815, where public technical detail is limited and the real risk is unpatched software quietly persisting in forgotten corners of the build pipeline, that continuous, artifact-level visibility is the difference between a vulnerability that gets fixed once and one that keeps resurfacing in every audit for years afterward.

If you're uncertain whether legacy .NET Core runtimes are still present anywhere in your software supply chain, that uncertainty is itself the finding worth acting on — Safeguard is built to replace it with an answer.