CVE-2022-38013: Denial of service in .NET via crafted req...

In September 2022, Microsoft disclosed CVE-2022-38013, a denial-of-service (DoS) vulnerability affecting the .NET platform. The flaw allows a remote, unauthenticated attacker to disrupt the availability of a .NET application simply by sending it a specially crafted request — no credentials, no user interaction, and no prior access required. For any team running internet-facing .NET services, this is exactly the kind of low-effort, high-disruption bug that belongs on the patch-now list, and it's a useful case study in why "dotnet denial of service crafted requests" is a search query worth taking seriously rather than skimming past.

What CVE-2022-38013 actually is

Microsoft's advisory describes CVE-2022-38013 in the terse, boilerplate language it reserves for .NET runtime denial-of-service issues: an attacker who successfully exploits the vulnerability can cause a denial of service against a .NET application, and exploitation requires sending a specially crafted request to that application. Unlike memory-corruption or remote-code-execution bugs, there is no code execution or data exposure implied here — the impact is squarely on availability. A successful attack can drive a target process into excessive resource consumption (CPU or memory) or an unhandled exception, causing the application or service to hang, crash, or stop responding to legitimate traffic.

That narrow impact profile matters for triage. Confidentiality and integrity are not affected; the risk is service disruption. But for anything that has to stay up — payment processing, authentication services, public APIs, customer-facing web apps — an unauthenticated, network-reachable DoS is still a serious operational risk, and it's cheap for an attacker to attempt since no exploit chaining or privilege escalation is needed first.

Affected versions and components

CVE-2022-38013 lives in the .NET runtime/SDK components that were under active servicing when Microsoft shipped its September 2022 updates. At that point in the .NET support lifecycle, the actively serviced branches were .NET Core 3.1 and .NET 6.0, both of which received their regular monthly runtime and SDK updates that month. Microsoft's standard practice for these advisories is to ship the fix through the normal .NET SDK and runtime release channel rather than as an out-of-band patch, which is consistent with how this CVE was remediated.

If you're trying to determine whether you're exposed, the practical questions are:

• Are you running a .NET application on a runtime or SDK version that predates the September 2022 servicing release for your branch?
• Is that application reachable from an untrusted network (the public internet, or any network segment an attacker could reach)?
• Do you have visibility into exactly which .NET runtime version is deployed in each of your services, containers, and build images?

That last question is often the hardest to answer honestly. .NET runtime versions get baked into container base images, CI build agents, and long-lived VMs, and they frequently drift out of sync with what a team assumes is "current." A denial-of-service CVE like this one is a good forcing function for an inventory exercise, because the fix is a routine update — the risk is not knowing you need it.

CVSS, EPSS, and KEV context

Microsoft classifies this class of .NET denial-of-service issue as Important severity rather than Critical, reflecting that the vulnerability affects availability only, with no confidentiality or integrity impact, and requires no authentication or user interaction to trigger over the network. That combination — network-exploitable, low complexity, no privileges needed, but availability-only impact — is the profile that typically produces a high-but-not-maximal CVSS base score in the 7.x range for this category of .NET advisory.

We haven't seen evidence that CVE-2022-38013 has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and there's no widely reported record of active, in-the-wild exploitation. EPSS scoring for vulnerabilities in this class also tends to stay comparatively low over time, since there's no public weaponized exploit driving broad opportunistic scanning, and the .NET ecosystem's monthly servicing cadence means the exposure window for well-maintained environments is typically short. That said, "no confirmed mass exploitation" is not the same as "safe to ignore" — DoS primitives against widely deployed runtimes are exactly the kind of thing that can get automated into scanning tools later, and unpatched instances remain a standing target indefinitely.

Timeline

• September 13, 2022 — Microsoft publicly disclosed CVE-2022-38013 as part of that month's Patch Tuesday release, alongside the regular monthly .NET Core and .NET 6.0 servicing updates.
• Same release cycle — Fixed runtime and SDK builds were made available through the standard .NET download channels and package feeds (NuGet, container registries, and OS package managers that track .NET releases), consistent with how Microsoft ships fixes for this vulnerability class.
• Since disclosure — No confirmed reports of widespread exploitation or KEV listing have surfaced. The vulnerability remains most relevant today as a reminder to keep .NET runtimes patched, and as a recurring finding in environments that have fallen behind on routine updates.

Because Microsoft did not publish granular technical exploitation detail in the advisory, exact discovery and reporting dates prior to public disclosure are not part of the public record — this is typical for DoS-class .NET CVEs, where the emphasis is on getting a fix shipped quickly rather than publishing a detailed root-cause writeup.

Remediation steps

1. Identify every affected surface. Inventory all .NET applications, services, and build/CI environments, and record the exact runtime and SDK version each one uses. Don't forget container base images, serverless functions, and internal tools — DoS-class bugs are easy to deprioritize on "non-critical" systems that still happen to be network-reachable.
2. Patch to a servicing release at or after Microsoft's September 2022 update for your .NET branch. Apply the update through your normal .NET update channel (SDK installer, package manager, or container base image rebuild) rather than attempting a manual workaround — there is no supported mitigation that avoids the need to update the runtime.
3. Rebuild and redeploy containers, not just hosts. If your applications run in containers, patching the underlying host's .NET installation does nothing if the container image bundles its own runtime. Rebuild affected images from an updated base and redeploy.
4. Validate the fix landed. Confirm the running runtime version in production (not just what's checked into your Dockerfile or CI config) matches or exceeds the patched version for your branch.
5. Add DoS-class .NET CVEs to your ongoing patch cadence. Because these issues are typically fixed through routine monthly servicing rather than emergency out-of-band releases, the biggest real-world risk is simply falling behind on regular updates. Treat .NET runtime patching as a scheduled, monitored process rather than a reactive one.
6. Add network-layer protections as a stopgap, not a substitute. Rate limiting, WAF rules, and request-size/complexity limits at the edge can reduce the blast radius of a DoS attempt while patches roll out, but they don't address the underlying vulnerability and shouldn't be treated as a long-term fix.

How Safeguard Helps

CVE-2022-38013 is a textbook example of the gap Safeguard is built to close: a vulnerability that's straightforward to fix once you know it applies to you, but easy to miss because it's buried in a runtime dependency rather than in your own application code.

Safeguard continuously inventories the actual runtimes, SDKs, and packages running across your build pipelines, containers, and production services — not just what's declared in a manifest, but what's genuinely deployed. That means when a CVE like this one is disclosed against a specific .NET servicing branch, Safeguard can immediately tell you which of your services, images, and environments are affected, without a manual audit.

Beyond detection, Safeguard's software supply chain visibility ties runtime and dependency versions back to the pipelines and artifacts that produced them, so remediation isn't just "update .NET somewhere" — it's a concrete list of which repos, build jobs, and deployed images need to be rebuilt and redeployed, and confirmation once they have been. For denial-of-service issues like CVE-2022-38013, where the fix is routine but the exposure window depends entirely on how quickly you can identify and patch every affected instance, that end-to-end visibility is what turns "we should probably check our .NET versions" into a tracked, verifiable remediation with a clear finish line.