The disclosure of CVE-2023-44487 in October 2023 revealed a practical denial-of-service attack against HTTP/2 that achieves significant resource exhaustion with low attacker cost. By sending rapid HEADERS and RST_STREAM frame sequences, a small number of clients can force servers to consume CPU, memory, and thread resources at scale. Production ASP.NET Core applications using Kestrel or IIS are directly exposed unless properly updated and configured.

Microsoft responded with patches that add reset rate tracking and aggressive connection closure when thresholds are exceeded. However, simply updating is not always enough. Operators must understand the configuration surfaces in both Kestrel and the Windows HTTP stack to fully mitigate the risk.

This post delivers the details developers need: how the attack works, the exact components impacted in the .NET ecosystem, and concrete code and configuration changes that reduce your exposure.

#How the HTTP/2 Rapid Reset Attack Functions

HTTP/2 multiplexes many streams onto one TCP connection. Each stream can be independently reset using an RST_STREAM frame. In a Rapid Reset attack the client immediately resets a stream after opening it. The server often performs initial processing for the stream before it receives and acts on the reset frame. Repeating this pattern thousands of times per second per connection allows an attacker to keep server thread pools busy and exhaust other internal resources.

The amplification comes from the fact that the client's work is trivial compared to the server's. Traditional per-IP rate limiting does not stop the attack because a single connection can generate enormous load before being closed. This is why protocol-level fixes were necessary in the HTTP/2 implementations themselves.

#Which .NET Deployments Are Affected

  • Kestrel-based ASP.NET Core apps running .NET runtimes released before the October 2023 security updates
  • Sites hosted on Windows Server using IIS with the ASP.NET Core hosting bundle and HTTP/2 enabled
  • Any environment where a reverse proxy terminates HTTP/2 but forwards unmitigated traffic to backend .NET services

#Actionable Steps to Mitigate the Vulnerability

First, update your infrastructure. Apply all current Windows Server security updates and upgrade to the latest ASP.NET Core runtime. These contain the necessary logic to detect and respond to rapid reset patterns by closing offending connections early.

csharp 
using Microsoft.AspNetCore.Server.Kestrel.Core;

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.Http2.MaxStreamsPerConnection = 100;
    options.Limits.Http2.InitialConnectionWindowSize = 65536;
    options.Limits.KeepAliveTimeout = TimeSpan.FromSeconds(30);
});

var app = builder.Build();
app.Run();
  • Validate that your deployed runtime matches the patched version by running 'dotnet --info' on your servers
  • Enable request rate limiting middleware in ASP.NET Core to provide defense in depth
  • Monitor application logs and performance counters for spikes in rejected streams or connection resets

#Maintaining Long-Term Protection

Web platform vulnerabilities require the same disciplined response as application CVEs. Establish automated patch management for both the OS and .NET components. Periodically review your Kestrel options against Microsoft's latest security baseline. Test your sites by simulating high connection churn to confirm that mitigations behave as expected under load.

By treating infrastructure security as a first-class concern alongside code quality, teams running .NET workloads on Windows can avoid outage incidents from protocol-level attacks like CVE-2023-44487.