CVE-2022-29145: Denial of service in .NET SignalR/Network...

CVE-2022-29145 is a denial-of-service (DoS) vulnerability in the .NET networking stack that underpins ASP.NET Core applications — including real-time frameworks like SignalR that hold long-lived connections open through the same Kestrel transport layer. Microsoft disclosed the issue as part of its May 2022 Patch Tuesday release, describing it as a flaw that lets a remote, unauthenticated attacker send specially crafted network traffic to a vulnerable endpoint and drive the server process into excessive resource consumption or an unresponsive state. The practical impact is straightforward: legitimate requests stop being served. There is no claim of data disclosure or tampering — this is an availability-only bug — but for services built on persistent connections, such as SignalR hubs pushing real-time updates to thousands of clients, an availability hit can be just as disruptive as a breach, especially if the affected process needs to be restarted to recover.

This class of bug is not exotic. Network-facing parsers and connection-handling code paths are a recurring source of DoS findings across every major runtime, and .NET has had several similar advisories in the same family of "malicious client sends malformed input, server burns CPU or hangs" issues. CVE-2022-29145 is one of those cases, and it's a useful example for supply chain security teams because the fix isn't something application developers can patch in their own code — it requires updating the underlying .NET runtime and SDK that every dependent service is built on.

Affected Versions and Components

The vulnerability sits in the .NET networking components used by ASP.NET Core to accept and process incoming connections — the layer that Kestrel, HTTP request handling, and higher-level frameworks like SignalR all depend on. Because SignalR doesn't implement its own transport from scratch, it inherits exposure from whatever connection-handling code the underlying .NET runtime ships with. That means the practical blast radius extends beyond "classic" web APIs to any real-time or messaging feature built on top of ASP.NET Core.

Microsoft's advisory covers the actively supported .NET release lines at the time: .NET Core 3.1 and .NET 6.0, along with the Visual Studio releases (2019 and 2022) that bundle those SDKs. Worth flagging for anyone doing an inventory sweep: .NET 5.0 reached end of support on May 10, 2022 — the same day this advisory was published — so no patched build was issued for it. Any service still running .NET 5.0 is not just vulnerable to this issue, it's permanently unpatched and needs to be moved to a supported release line regardless of this specific CVE.

Self-hosted and containerized deployments are worth calling out specifically. Unlike a library dependency that shows up in a lockfile, the .NET runtime version is often baked into a base container image or an SDK installation on a build agent, which makes it easy to lose track of across a fleet of services. Teams that pin base images (e.g., mcr.microsoft.com/dotnet/aspnet:6.0) without a process for tracking and bumping patch-level tags are the most likely to still be carrying this vulnerability today.

CVSS, EPSS, and KEV Context

Microsoft rated this class of .NET denial-of-service issue as High severity, consistent with a CVSS 3.1 profile of network-exploitable, low attack complexity, no privileges required, and no user interaction — an unauthenticated attacker only needs network reachability to the affected endpoint to attempt exploitation. The impact is scored as availability-only, with no confidentiality or integrity impact, which is the expected profile for a resource-exhaustion or hang-style bug rather than a memory-corruption or logic flaw.

On exploitation likelihood: this CVE has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of active exploitation in the wild. Its EPSS score is consistent with other unexploited, non-weaponized .NET DoS advisories — low relative to CVEs with public proof-of-concept code or documented exploitation, but not zero, since the vulnerability class (crafted-input DoS against a widely deployed web framework) is exactly the kind of low-effort, high-reach target that opportunistic scanning eventually reaches. Absence from KEV and a low EPSS score are useful signals for prioritization, but they are not a reason to defer patching indefinitely — DoS bugs against internet-facing services are cheap for an attacker to test blindly across large IP ranges, whether or not anyone has published a named exploit.

Timeline

• Prior to May 2022 — Vulnerability identified and reported through Microsoft's coordinated disclosure process (MSRC); as with most Microsoft advisories, the initial private reporting date was not made public.
• May 10, 2022 — Microsoft published the advisory for CVE-2022-29145 as part of the May 2022 Patch Tuesday cycle, alongside updated .NET 6.0 and .NET Core 3.1 runtime/SDK builds and corresponding Visual Studio updates. This is also the date .NET 5.0 reached end of support, meaning it received no fix.
• Post-disclosure — No subsequent reports of in-the-wild exploitation or public proof-of-concept code have materially changed the risk profile; the CVE remains outside CISA KEV.

Remediation Steps

1. Update the .NET runtime and SDK. Move affected .NET 6.0 and .NET Core 3.1 installations to the patched builds released in the May 2022 update cycle. Run dotnet --list-runtimes and dotnet --list-sdks across build agents, hosts, and containers to confirm what's actually deployed rather than relying on what a Dockerfile or CI config claims.
2. Retire .NET 5.0 entirely. Because .NET 5.0 hit end-of-support on the same day this advisory shipped, there is no patched version to move to within that release line — the only fix is migrating affected applications to .NET 6.0 (or later LTS) or .NET Core 3.1's supported patch stream.
3. Rebuild and redeploy, don't just patch hosts. For containerized services, bump the base image tag (e.g., to the patched aspnet:6.0 digest) and rebuild — patching the underlying OS or runtime on a running host without rebuilding the image means the next deployment reintroduces the vulnerable version.
4. Update Visual Studio and build tooling. Since Visual Studio bundles its own copy of the .NET SDK, developer workstations and build servers need the corresponding VS update in addition to the runtime patch on production hosts.
5. Add network-layer mitigations as defense in depth. Rate limiting, connection throttling, and WAF rules in front of internet-facing ASP.NET Core and SignalR endpoints reduce the practical impact of resource-exhaustion attempts even after patching, and buy time for services that can't be patched immediately.
6. Verify SignalR and real-time services specifically. Because these components inherit transport behavior from the shared networking stack, don't assume a patch to "the web API" also covered a separately-deployed SignalR backend or hub — check each service's actual runtime version independently.

How Safeguard Helps

CVE-2022-29145 is a good illustration of a broader supply chain blind spot: the vulnerability doesn't live in a package your team wrote or even a NuGet dependency you explicitly pulled in — it lives in the runtime itself, often pinned inside a base image or installed on a build agent that nobody is actively tracking for CVEs. That's precisely the gap Safeguard is built to close.

Safeguard continuously generates and maintains SBOMs across your services, containers, and build infrastructure, capturing runtime and SDK versions — not just application-level dependencies — so a .NET 5.0 or unpatched .NET 6.0 installation shows up in inventory before it becomes an incident. When a CVE like this one is disclosed, Safeguard maps it automatically against that live inventory, flagging every affected service, container image, and build agent instead of leaving teams to manually cross-reference Patch Tuesday bulletins against a spreadsheet of deployments.

Safeguard also layers in exploitability context — CVSS severity, EPSS trend, and KEV status — so teams can correctly prioritize a High-severity-but-unexploited DoS bug relative to whatever else is competing for engineering time that sprint, rather than treating every CVE as equally urgent. And because the real fix here requires a rebuild rather than a config change, Safeguard's CI/CD policy gates can block promotion of images or builds still referencing vulnerable .NET runtime tags, closing the loop between detection and actual remediation instead of stopping at a dashboard alert.

For unsupported release lines like .NET 5.0, Safeguard's inventory tracking also helps surface end-of-life runtimes proactively — flagging them as permanent risk exposure even before a specific CVE forces the conversation, so migrations happen on a planned timeline rather than as an emergency response.