CVE-2023-33170: Denial of service in .NET SocketsHttpHandler

A specially crafted HTTP response is all it takes to knock a .NET service offline. CVE-2022-23267 is a denial-of-service vulnerability in .NET's HTTP stack — specifically in the memory-handling path used by HttpClient and its default transport, SocketsHttpHandler. A remote party that controls (or can spoof) the server side of an HTTP connection can force a vulnerable .NET client to allocate excessive, effectively unbounded memory while processing a response, driving the process toward resource exhaustion and crash or unresponsiveness.

Before going further, a factual note for anyone who landed here searching a different CVE ID: CVE-2023-33170 is a separate and unrelated advisory — a race condition in ASP.NET Core Identity's account-lockout logic (CWE-362) that can let an attacker exceed the configured maximum failed login attempts. It has nothing to do with SocketsHttpHandler or HTTP response processing. The vulnerability this post covers, the one actually matching "dotnet socketshttphandler denial of service," is CVE-2022-23267, published by Microsoft in May 2022. Getting the identifier right matters for accurate patch tracking, so we're calling it out explicitly.

The Vulnerability

SocketsHttpHandler has been the default, fully managed HttpMessageHandler implementation backing HttpClient since .NET Core 2.1. It is responsible for everything from connection pooling to parsing response headers off the wire. Per Microsoft's advisory and corroborating vendor analyses, the flaw involves how the handler applies the MaxResponseHeadersLength limit to trailing headers — the optional header block that can follow a chunked-transfer-encoded HTTP body. Trailing headers were not properly bounded by that same length limit, so a response engineered to include an excessive volume of trailer data could cause the client to keep allocating memory well past the limit an application had configured as a safety ceiling.

The practical effect: any .NET process that uses HttpClient (directly, through IHttpClientFactory, or transitively through a library) to talk to a server it does not fully trust — a third-party API, a partner integration, a proxied backend, a webhook responder — could be driven to out-of-memory conditions or severe slowdown by a malicious or compromised endpoint on the other side of that connection. This is the class of bug that's easy to overlook because it lives in the runtime's networking stack rather than in application code or a NuGet dependency, so it doesn't show up in a typical dotnet list package --vulnerable scan the way a compromised package would.

Microsoft's own advisory language frames the trigger as a "malicious client," but the underlying mechanism — uncontrolled resource consumption while parsing an HTTP response inside HttpClient/SocketsHttpHandler — places the exploitable behavior squarely on the response-processing path. Microsoft stated it had not identified any mitigating factors for this vulnerability, meaning there was no configuration workaround short of patching.

Affected Versions and Components

The vulnerability is rooted in the shared .NET runtime, not an application-level package, so it affects the runtime itself and anything that bundles it:

• .NET 6.0 — versions 6.0.0 through 6.0.4
• .NET 5.0 — versions 5.0.0 through 5.0.16
• .NET Core 3.1 — versions 3.1.0 through 3.1.24
• Visual Studio 2019 — 16.0–16.9.20 and 16.10–16.11.13 (bundled SDK/runtime)
• Visual Studio 2022 — 17.0.0–17.0.9 and 17.1.0–17.1.6, and Visual Studio 2022 for Mac 17.0.0–17.0.2
• PowerShell — 7.0 before 7.0.11 and 7.2 before 7.2.4 (both ship on the .NET runtime)

Because the fix lives in Microsoft.AspNetCore.App.Runtime and the core shared framework, the exposure isn't limited to ASP.NET Core web apps — any .NET 6.0/5.0/3.1 process making outbound HTTP calls is in scope, including console apps, Windows services, Azure Functions, and containerized microservices.

Severity: CVSS, EPSS, and KEV Status

Microsoft rated CVE-2022-23267 7.5 (High) under CVSS 3.1, with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — network-exploitable, low attack complexity, no privileges or user interaction required, and an availability-only impact (no confidentiality or integrity loss). An older CVSS 2.0 score of 5.0 (Medium) is also on file from early tracking. It is generally categorized as an uncontrolled resource consumption issue (CWE-400-style behavior), consistent with a memory-exhaustion denial of service.

On the exploitation-likelihood side, this CVE's EPSS score sits in the low single digits (roughly 5% predicted probability of exploitation in the next 30 days as of current scoring), though its percentile ranking is comparatively high relative to the broader CVE population — a pattern typical of older, well-documented DoS bugs that get periodic scanning attention without becoming a live mass-exploitation campaign. We found no evidence that CVE-2022-23267 appears in CISA's Known Exploited Vulnerabilities (KEV) catalog, and no public reporting of confirmed in-the-wild exploitation. That combination — high CVSS severity, low-to-moderate EPSS, no KEV listing — is a common profile for runtime-level DoS flaws: dangerous if you're exposed and unpatched, but not the subject of widespread automated attack traffic. Severity alone shouldn't be the only signal driving patch prioritization; exposure (does this service make outbound calls to untrusted or attacker-influenceable endpoints?) matters just as much.

Timeline

• May 10, 2022 — Microsoft published the security advisory and the corresponding NVD/MSRC entries for CVE-2022-23267, coinciding with .NET's monthly servicing release. Fixed runtimes shipped the same day: .NET 6.0.5 (SDK 6.0.105 for Visual Studio 17.0, or 6.0.203 for 17.1), .NET 5.0.17, and .NET Core 3.1.25.
• May 2022 — Companion fixes for Visual Studio 2019/2022 (bundled SDKs) and PowerShell 7.0.11 / 7.2.4 followed as part of the same coordinated release, since those products embed the affected .NET components.
• October 21, 2022 — The vulnerability was mirrored into the GitHub Advisory Database (GHSA-485p-mrj5-8w2v), extending its visibility to dependency-scanning and SBOM tooling that consumes that feed.
• December 13, 2022 — .NET Core 3.1 reached end of support, meaning organizations still running unpatched 3.1 builds today are carrying both this specific DoS exposure and the broader risk of an out-of-support runtime with no future security fixes.

Remediation Steps

1. Upgrade the runtime, not just the SDK. Move to .NET 6.0.5 or later, .NET 5.0.17 or later, or .NET Core 3.1.25 or later, depending on your target framework. For .NET Core 3.1, remember it's now out of support entirely — treat this as a forcing function to plan a migration to a supported LTS release (.NET 6 or later).
2. Redeploy self-contained applications. If any service is published as a self-contained deployment (bundling its own copy of the runtime rather than relying on a shared, host-installed one), patching the machine's shared runtime does nothing for it. Those apps must be rebuilt against a patched runtime and redeployed — a step that's frequently missed in large fleets.
3. Rebuild and re-tag container images. Any container image pinned to a vulnerable mcr.microsoft.com/dotnet/* base image tag needs to be rebuilt from an updated base and redeployed. Pinning by digest without a refresh process is exactly how this kind of runtime CVE lingers silently in production for months.
4. Patch bundled tooling. Update Visual Studio installations to the patched builds referenced above, and update PowerShell to 7.0.11+ or 7.2.4+ where those versions are in use for automation or CI tooling.
5. Verify, don't assume. After patching, confirm the actual running runtime version in each environment (dotnet --info or equivalent runtime identification in production) rather than trusting that a CI pipeline change alone propagated everywhere. Runtime-level CVEs are notorious for surviving in edge deployments, legacy VMs, and infrequently rebuilt images.
6. Review outbound HTTP exposure. Since there's no configuration mitigation, prioritize patching for services that make outbound HttpClient calls to third-party, partner, or otherwise less-trusted endpoints — that's the concrete exploitation path for this bug.

How Safeguard Helps

Runtime-level vulnerabilities like CVE-2022-23267 are exactly the kind of risk that slips through gaps between application-dependency scanning and infrastructure patch management — they don't show up as a vulnerable NuGet package, and they're easy to miss in self-contained deployments or container images that were built once and never revisited.

Safeguard closes that gap by treating the .NET runtime itself as a first-class, tracked component of your software supply chain. We generate and continuously reconcile SBOMs across your services, container images, and build artifacts, so a vulnerable runtime version — whether it's sitting in a shared host install, baked into a self-contained deployment, or frozen into an old container layer — is identified the moment it enters your environment, not months later during an incident review. We correlate that inventory against NVD, GitHub Security Advisories, vendor bulletins, and EPSS/KEV feeds in real time, so teams get severity and exploitation-likelihood context alongside the raw CVE match, rather than having to chase down CVSS vectors and EPSS scores by hand across half a dozen disconnected sources.

When a runtime CVE like this one lands, Safeguard flags every affected build artifact and deployment target across your fleet, distinguishes patched from unpatched instances by actual verified runtime version (not just base-image tag assumptions), and routes remediation work to the owning team with the specific upgrade path already identified. For organizations that need to demonstrate patch SLAs under SOC 2 or similar frameworks, that same evidence trail — detection timestamp, remediation timestamp, verified fixed version — becomes part of your compliance record automatically, instead of a manual audit scramble. The goal is straightforward: when the next .NET runtime CVE drops, you know within minutes exactly where you're exposed, instead of discovering it when a service starts falling over in production.