CVE-2023-36799: Denial of service in .NET Core

In October 2023, Microsoft disclosed CVE-2023-36799, a denial-of-service (DoS) vulnerability in the .NET runtime — the cross-platform, actively developed successor to .NET Core. An attacker who successfully exploits the flaw can degrade or crash an affected .NET process, disrupting availability for anything running on top of it: internal APIs, background workers, gRPC services, or public-facing ASP.NET Core applications. Because the flaw lives in the runtime rather than in application code, it is a useful case study in why supply chain visibility has to extend below the application layer, down into the runtimes and base images that every service depends on.

Affected versions and components

CVE-2023-36799 sits in the shared .NET runtime rather than in a specific NuGet package, application framework, or first-party library. That distinction matters: an application can be free of known-vulnerable dependencies in its lockfile and still be exposed, because the exposure travels with the runtime binary the process is actually executed by, not with anything declared in a .csproj or packages.lock.json.

Microsoft's advisory ties the fix to the .NET servicing releases published alongside the October 2023 Patch Tuesday cycle, covering the .NET 6.0 (LTS) and .NET 7.0 (STS) release trains that were in mainstream support at the time. Since .NET 6 and .NET 7 are the direct successors to .NET Core 3.1, and many organizations still refer to their entire .NET 5+ estate informally as ".NET Core" in asset inventories and ticketing systems, teams should not assume the naming difference means the CVE doesn't apply to them. If your inventory tags a service as ".NET Core," check what runtime major version it actually executes on before ruling this CVE out.

Runtimes that were already out of support at disclosure time — .NET Core 3.1, .NET 5, and earlier — did not receive a fix. If any of those are still running in your environment, this advisory is one more concrete reason to prioritize the runtime upgrade rather than continuing to patch around an unsupported base.

CVSS, EPSS, and KEV context

Microsoft rated CVE-2023-36799 as "Important" severity, its standard classification for denial-of-service issues that are remotely reachable but don't affect confidentiality or integrity. Public vulnerability trackers list a CVSS 3.1 base score in the high range, commonly reported around 7.5, reflecting a network attack vector, low attack complexity, no privileges required, no user interaction, and high impact to availability with no impact to confidentiality or integrity — a scoring profile typical of resource-exhaustion bugs in request-handling code paths.

As of this writing, CVE-2023-36799 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there are no widely reported instances of confirmed in-the-wild exploitation or public proof-of-concept exploit code. EPSS scores for this class of coordinated-disclosure .NET DoS advisory have generally sat in the low percentile range, consistent with a vulnerability that is technically exploitable but hasn't attracted mass internet scanning or weaponized tooling.

It's worth being careful about how much comfort to take from that. A low EPSS score and absence from KEV describe current, observed exploitation activity — they don't guarantee the bug stays quiet. Availability-impacting flaws in a runtime as widely deployed as .NET are attractive targets once technical details are reverse-engineered from a patch diff, and EPSS scores can move quickly if that happens. Treat "not currently exploited" as a snapshot, not a reason to deprioritize patching.

Timeline

• Disclosure and patch (October 2023): Microsoft published the advisory for CVE-2023-36799 and shipped the fix through its regular monthly .NET servicing release, aligned with the October 2023 Patch Tuesday cycle.
• Cataloging: The issue was assigned a CVE identifier and indexed in NVD and downstream vulnerability databases shortly after, alongside Microsoft's guidance to update to the patched .NET 6.0 and .NET 7.0 servicing builds.
• Post-disclosure period: No confirmed reports of active exploitation or KEV listing have followed. The main practical risk since disclosure has been organizational lag — services running unpatched runtime builds for weeks or months after the fix shipped, which is the window during which a patch diff could plausibly be reverse-engineered into a working denial-of-service trigger.

Remediation steps

1. Inventory your .NET runtime versions across every environment, not just source repositories. Identify services, container images, CI/CD build agents, and serverless deployment packages running .NET 6.0 or .NET 7.0, and flag anything that predates the October 2023 servicing release.
2. Patch the runtime, not just the SDK. DoS fixes of this kind live in the shared runtime, so container images built FROM mcr.microsoft.com/dotnet/aspnet or mcr.microsoft.com/dotnet/runtime need to be rebuilt against an updated base image tag or digest — recompiling with a newer SDK alone does not pull in the fix if the runtime layer isn't refreshed.
3. Rebuild and redeploy affected containers deliberately. Because the fix ships in the runtime layer, redeploying an existing image without rebuilding it changes nothing. Audit Dockerfiles, base image pinning, and any cached layers for stale digests that predate the patch.
4. Add defense in depth at the edge. Rate limiting, request size caps, and aggressive timeouts at the reverse proxy, load balancer, or API gateway reduce the blast radius of denial-of-service issues broadly, independent of whether every downstream service has been patched yet.
5. Confirm the patch actually landed in production, not just in a global.json pin or build manifest. Configuration drift between what a Dockerfile declares and what's actually deployed is one of the most common reasons a "patched" CVE remains exploitable in the running fleet.
6. Retire unsupported runtimes. If part of the estate is still on .NET Core 3.1 or .NET 5, this CVE received no fix for those versions — the only real remediation is migrating those workloads onto a supported release train.

How Safeguard Helps

CVE-2023-36799 illustrates a gap that dependency scanning alone doesn't close: the vulnerability isn't in a package your team chose, it's in the runtime underneath every package you chose. Catching that requires visibility that spans source code, build pipelines, and the actual artifacts running in production — not just a lockfile snapshot.

Safeguard's software supply chain platform is built for exactly this gap. It continuously inventories the runtimes, base images, and language versions actually deployed across your services — generating and maintaining SBOMs that capture the .NET runtime version a container is built on, not just the application-level dependencies declared in its manifest. When a new advisory like CVE-2023-36799 is published, Safeguard maps it against that live inventory and flags every image, service, and build pipeline still running an affected runtime version, so security and platform teams don't have to manually cross-reference Microsoft's advisory against a spreadsheet of container tags.

Safeguard also closes the loop on remediation verification. Because the fix for a runtime-level bug like this requires rebuilding and redeploying images rather than just bumping a version string in source, Safeguard tracks whether the patched runtime digest is actually present in what's running — surfacing drift between what a Dockerfile declares and what's deployed, so a "patched" status reflects reality rather than intent. Combined with policy gates in CI/CD that block builds on runtime images past their patch window, this turns a manual, advisory-by-advisory scramble into a continuous, auditable control — the kind of evidence that also supports SOC 2 and other compliance obligations around vulnerability management timelines.

For teams that want to know, right now, whether any service in their fleet is still exposed to CVE-2023-36799 or the next runtime-level advisory that follows it, that continuous mapping between advisories and actual deployed artifacts is the difference between reacting to a CVE and already having answered it.