CVE-2021-26701: Remote code execution in .NET Core

In February 2021, Microsoft disclosed CVE-2021-26701, a remote code execution vulnerability in .NET Core rooted in how the runtime processed text encoding. The advisory description was terse but serious: an attacker who could get a .NET Core application to process specially crafted input could execute arbitrary code in the context of the user running that application — and if that user held administrative rights, the attacker could take control of the affected system outright. For any organization running .NET Core services that accept untrusted input (which is to say, most of them), this was a patch-now advisory, not a patch-eventually one.

CVE-2021-26701 is a useful case study precisely because it's unglamorous. It didn't come with a catchy name, a logo, or a proof-of-concept fire drill on social media. It was one of several .NET-related CVEs Microsoft shipped fixes for in the same update cycle, and it's easy to see how a vulnerability like this slips through patch management processes that aren't systematically tracking runtime and framework versions across a software estate. That's exactly the gap supply chain security tooling exists to close.

Affected Versions and Components

The vulnerability affected the .NET Core runtime and, by extension, any application built on top of it. Per Microsoft's advisory, the affected product lines were .NET Core 2.1, .NET Core 3.1, and .NET 5.0 — the actively supported branches at the time of disclosure. The root cause was described as an issue in how .NET Core processed text encoding; a specially crafted input handled by a vulnerable application could trigger the flaw, giving the vulnerability a network-reachable, application-layer attack surface rather than requiring local access.

Because .NET Core underpins a huge range of ASP.NET Core web applications, APIs, and backend services, the practical exposure wasn't limited to a niche component — it touched any team running an internet-facing or otherwise input-processing .NET Core workload on one of the affected branches. Organizations running .NET Core 2.1 in particular were on notice for another reason: that branch was approaching the end of its support lifecycle later in 2021, making this one of the last rounds of security servicing it would receive before Microsoft stopped shipping fixes for it entirely.

CVSS, EPSS, and KEV Context

Microsoft rated CVE-2021-26701 as an Important severity vulnerability in its own severity classification, its second-highest rating tier, reflecting real-world exploitability tempered by the fact that exploitation depended on an application actually feeding attacker-controlled input into the vulnerable code path. NVD's CVSS scoring places it in the high-severity band consistent with a network-exploitable remote code execution flaw; we'd encourage readers to check the current NVD entry directly for the exact base score and vector string, since third-party scoring occasionally gets revised after initial publication and we don't want to reproduce a stale figure here.

On the EPSS and KEV front, we're not aware of CVE-2021-26701 ever appearing on CISA's Known Exploited Vulnerabilities (KEV) catalog, and we have not seen credible reporting of it being exploited in the wild, either at disclosure or since. EPSS scores for CVEs without observed exploitation activity typically settle at the low end of the scale over time, and that pattern is consistent with what's publicly visible for this CVE. In other words: this was a real, high-impact vulnerability worth patching promptly, but it does not appear to have become an active exploitation target the way some contemporaneous RCEs did. That distinction matters for prioritization — but it should not be mistaken for "low priority." Un-exploited today doesn't mean un-exploitable tomorrow, especially once a runtime version drifts out of support and stops receiving fixes for anything discovered later.

Timeline

• February 9, 2021 — Microsoft's February 2021 Patch Tuesday cycle shipped the fix for CVE-2021-26701 alongside updates for the affected .NET Core and .NET 5.0 branches, as part of Microsoft's regular monthly security release process.
• Ongoing — .NET Core 2.1 reached the end of its support lifecycle later in 2021 (August 21, 2021), meaning organizations still running that branch after that date stopped receiving security fixes for any future vulnerabilities, CVE-2021-26701 included in the sense that no further patches would follow for that line.
• Since disclosure — No widely reported incidents of in-the-wild exploitation have surfaced, and the CVE has not appeared on CISA's KEV list, consistent with a vulnerability that was patched broadly before attackers built reliable exploitation tooling for it.

We're intentionally not asserting a specific discovery date, a named discoverer, or an exact patch build number here — those details vary across secondary sources, and we'd rather point you to Microsoft's official advisory and NVD entry for the authoritative record than repeat a number we can't independently verify.

Remediation Steps

1. Identify every .NET Core and .NET 5.0 instance in your environment. This includes not just standalone deployed applications but containers, VM images, CI/CD build agents, and any third-party or internal tooling that bundles a specific .NET Core runtime version. Version drift hides in places teams don't think to check.
2. Apply the February 2021 (or later) security updates for whichever .NET Core or .NET 5.0 branch you run. If you're managing patching through a package manager, container base image, or SDK installer, confirm the update actually propagated to running instances — a patched base image that hasn't been rebuilt and redeployed provides no protection.
3. Migrate off .NET Core 2.1 if you haven't already. With that branch out of support since August 2021, it no longer receives fixes for anything found after that point. If CVE-2021-26701 doesn't motivate the move, the accumulated backlog of everything patched in supported branches since should.
4. Validate and sanitize input at trust boundaries, independent of runtime patch status. Defense in depth matters here: a vulnerability tied to text encoding processing is a reminder that input validation belongs at the application layer too, not just the runtime layer.
5. Re-scan and re-verify after patching. Confirm via version checks or vulnerability scanning that the deployed runtime version no longer reports as vulnerable, rather than assuming a patch job succeeded because it was scheduled.
6. Track EOL dates for your framework versions going forward. Building end-of-life monitoring into your patch cadence prevents a repeat of the "still on an unsupported branch" problem the next time a .NET CVE lands.

How Safeguard Helps

CVE-2021-26701 is a textbook example of the kind of risk that hides in plain sight across a software supply chain: a widely used runtime, multiple actively supported branches, and an update that's easy to miss if you're not systematically tracking what version of .NET Core is actually running in every service, container, and build pipeline you own.

Safeguard is built to close exactly that visibility gap. Instead of relying on point-in-time manual audits, Safeguard continuously inventories the components in your software supply chain — including runtime and framework dependencies like .NET Core — and maps them against known vulnerabilities as they're disclosed. When a CVE like this one lands, Safeguard can tell you immediately which of your services, images, and build artifacts are running an affected .NET Core or .NET 5.0 version, rather than leaving that discovery to a manual grep through deployment manifests after the fact.

Because not every disclosed CVE carries the same urgency, Safeguard layers in severity, exploitation, and KEV context — the same kind of signal we walked through above — so your team can prioritize the handful of vulnerabilities that actually warrant an emergency patch cycle over the much larger set that can be handled in the normal cadence. That distinction is what keeps a security team from drowning in advisories while still catching the ones that matter.

Safeguard also flags components approaching or past end-of-life, like .NET Core 2.1's lifecycle cutoff, before that lapse becomes a compliance finding or an unpatched exposure. For teams working toward SOC 2 or similar attestations, that combination of continuous component inventory, CVE mapping, and remediation tracking turns "did we patch CVE-2021-26701 everywhere it applied?" from an open question into a verifiable answer.

If your organization is still validating whether every .NET Core and .NET 5.0 deployment received the February 2021 update — or whether any service is still quietly running an unsupported 2.1 build — that's precisely the kind of gap Safeguard is designed to surface before it becomes an incident.