SAN FRANCISCO — July 6, 2026. ASP.NET Core has spent the last three years quietly becoming one of the most consequential runtimes in enterprise software — powering everything from Azure-native SaaS platforms to on-prem line-of-business apps at Fortune 500 companies. That popularity has a cost. A review of National Vulnerability Database (NVD) entries tagged to Microsoft.AspNetCore.* and System.Net.* packages shows a steady cadence of disclosures tied to the framework and its first-party dependencies: denial-of-service flaws in Kestrel and SignalR, authentication and certificate-validation bypasses, and a recurring category of deserialization bugs in JSON and MessagePack handling. Microsoft's own Patch Tuesday releases have shipped .NET/ASP.NET Core fixes in the majority of monthly cycles going back to 2023, and several — including CVE-2023-36414, CVE-2023-33170, CVE-2024-30105, CVE-2024-38095, and CVE-2024-38229 — carried CVSS scores in the 6.5–8.6 range, high enough to trigger emergency patch windows for regulated customers.
This is not a story about one catastrophic zero-day. It's a story about volume, velocity, and the widening gap between when a fix ships and when it actually reaches production. That gap is where most of the real-world risk in the ASP.NET Core ecosystem now lives.
Denial-of-Service Has Become the Framework's Signature Bug Class
If you plot ASP.NET Core CVEs by category over the past three patch cycles, denial-of-service consistently comes out on top — ahead of remote code execution, information disclosure, and spoofing combined. Kestrel's HTTP/2 and HTTP/3 request-handling paths, along with SignalR's connection-management logic, have been the recurring source. CVE-2024-38095 (SignalR DoS) and CVE-2023-33170 (SignalR DoS via MessagePack) both allowed a remote, unauthenticated attacker to exhaust server resources through malformed or oversized payloads — no credentials, no user interaction, just a crafted request.
The pattern tracks with how ASP.NET Core is actually deployed: as an internet-facing API gateway or real-time backend (SignalR is the default choice for anything requiring WebSockets at scale), which means these services sit directly in an attacker's line of sight. For a framework historically associated with "enterprise, buttoned-up, boring," the DoS concentration is a reminder that availability risk scales with adoption. The more mission-critical systems that run on Kestrel, the more attractive it becomes to knock them offline rather than compromise them outright.
Deserialization and Input Validation: The Bugs That Keep Coming Back
The second recurring theme is input handling — specifically JSON, XML, and binary deserialization paths. CVE-2024-30105 (a .NET JSON DoS issue) and older findings in System.Text.Json and Newtonsoft.Json interop layers illustrate a durable truth: deserialization is still one of the hardest problems in managed runtimes to fully close off, because the attack surface reappears every time a new serializer, a new content-type negotiation path, or a new model-binding convention gets added. ASP.NET Core's model binding, in particular, has been a repeat source of advisories because it sits at the exact seam where untrusted network input becomes typed application objects — the textbook definition of a security-critical boundary.
What makes this category dangerous in practice isn't the individual bug — Microsoft has generally patched these within a single release cycle — it's that model-binding and serialization code paths are buried deep inside framework internals that most application teams never audit themselves. Teams inherit the risk simply by taking a NuGet update, with little visibility into whether the specific code path they use is even reachable.
The NuGet Supply Chain Angle
ASP.NET Core doesn't run in isolation — a typical production service pulls in 40 to 150+ transitive NuGet packages once you count logging, telemetry, ORM, and cloud-SDK dependencies. That dependency graph is now a favored target in its own right. Typosquatting campaigns against popular NuGet package names, credential-harvesting packages disguised as internal-sounding utility libraries, and compromised maintainer accounts have all been documented on the NuGet gallery in the past two years, echoing the same supply chain patterns that have hit npm and PyPI. NuGet's own tooling improvements — package signing enforcement, audit warnings for known-vulnerable packages surfaced directly in dotnet restore and dotnet list package --vulnerable — are a direct response to this pressure, but adoption of those controls varies wildly across engineering orgs, especially ones running older SDK versions that predate the tooling.
The net effect: a meaningful share of "ASP.NET Core" risk isn't in Microsoft's own code at all. It's in the third-party and transitive dependency tree that ships alongside it, which is exactly the layer that's hardest for a security team to see without dependency-graph tooling.
Patch Tuesday Cadence vs. the Real-World Window of Exposure
Microsoft's monthly Patch Tuesday cadence gives .NET shops a predictable rhythm to plan around — but predictability isn't the same as speed. Enterprise change-management processes routinely add two to six weeks between a patch's release and its rollout to production, and that's before accounting for services running on .NET versions that are approaching or past end-of-support, where a fix may not be backported at all. .NET 6 reached end of support in November 2024; organizations still running services on it for CVEs disclosed afterward are, by definition, unpatched by design, not by delay.
The compounding factor is discovery time. Security teams scanning for "ASP.NET Core vulnerabilities" via package-version matching alone will flag every application using an affected package version — regardless of whether the vulnerable code path is ever invoked. For a framework where a large share of high-severity findings are DoS or edge-case deserialization bugs buried in optional feature paths (specific SignalR transports, specific JSON converter configurations), that's a lot of noise for triage teams to wade through before they find the handful of findings that represent genuine, exploitable exposure.
What This Means for Enterprise .NET Shops
Three practical implications fall out of this pattern:
- Version currency is now a security control, not a maintenance chore. Every month a service stays on an out-of-support .NET release, its exposure to newly disclosed CVEs compounds with no patch path available.
- Not every flagged CVE deserves the same response time. A Kestrel DoS bug in an HTTP/3 code path your service never enables is a very different risk than a deserialization bug in the exact JSON converter your API actually uses in an internet-facing controller.
- The NuGet dependency tree deserves the same scrutiny as first-party code. SBOM visibility into transitive packages — not just the top-level references in your
.csproj— is what separates teams that catch a compromised or vulnerable package early from teams that find out during an incident.
How Safeguard Helps
Safeguard is built for exactly this triage problem in the .NET ecosystem. Our reachability analysis traces whether a disclosed ASP.NET Core or NuGet CVE — like the Kestrel and SignalR DoS issues above — actually sits on a code path your application invokes, so teams can stop burning cycles on theoretical findings and focus on the exploitable ones. Griffin AI, Safeguard's security reasoning engine, correlates that reachability data with each service's exposure context (internet-facing, authenticated, internal-only) to prioritize the small subset of findings that represent real risk. Automatic SBOM generation and ingest give you continuous visibility into the full NuGet dependency graph — first-party and transitive — so a typosquatted or compromised package doesn't sit undetected for months. And where a fix is available, Safeguard opens auto-fix pull requests that bump the affected package to a patched version, cutting the gap between disclosure and remediation from weeks to hours.