In October 2023, security researchers disclosed CVE-2023-44487, a vulnerability in the HTTP/2 protocol that permits low-bandwidth, high-impact denial of service attacks. The technique, known as Rapid Reset, has been used to generate hundreds of thousands of requests per second from individual clients, overwhelming CPU and connection resources on the server side. If you run production ASP.NET Core applications on Windows Server or Linux hosts using Kestrel or IIS, this advisory applies directly to you.

The vulnerability is not a bug in application code but in the protocol implementation itself. By rapidly opening and resetting HTTP/2 streams, attackers force servers to perform unnecessary work while keeping connections open for further abuse. Vendors including Microsoft have issued patches that improve stream handling and add internal rate limits. However, patching alone is insufficient; developers must also review configuration and add defense-in-depth measures.

Below we outline the attack mechanics, list the exact components in the ASPnix .NET hosting stack that require attention, and provide copy-paste ready configuration and code samples to lock things down. Follow these steps to ensure your sites remain available under sustained attack.

#Technical Details of the Rapid Reset Attack

HTTP/2 multiplexes requests using streams over a single TCP connection. After a client sends the HEADERS frame to start a new stream, the server allocates resources and begins processing. The client then immediately follows with an RST_STREAM frame, cancelling the request. Because the cancellation arrives after initial processing has started, the server has already spent CPU time. Repeating this pattern at rates of 10,000 to 100,000 times per second per connection exhausts server resources quickly. The attack scales horizontally when the attacker opens multiple concurrent connections.

What makes this attack especially dangerous is its efficiency. Traditional volumetric DDoS attacks require massive bandwidth. Rapid Reset achieves similar disruption with only a few megabits per second because the server does the heavy lifting. Early testing showed popular web servers and CDNs could be knocked offline within seconds.

#Affected Components

  • Kestrel server in ASP.NET Core versions released before the October 2023 security patches
  • IIS when HTTP/2 protocol is enabled (default on newer Windows Server versions)
  • Windows Server 2022, 2019, and 2016 running .NET web workloads
  • Any deployment using unpatched reverse proxies that forward HTTP/2 traffic

Applications using older .NET Framework versions on IIS are also impacted if HTTP/2 is enabled. The common thread is any software that implements the HTTP/2 specification without limits on stream creation and reset velocity.

#Patching Your Environment

Start by updating the operating system and runtime. On ASPnix control panels you can trigger runtime updates directly. For self-managed Windows instances, run Windows Update and specifically install any security rollups released after mid-October 2023. Verify your .NET runtime with the command line tool to confirm you are on a patched build.

bash 
dotnet --list-runtimes

After updating, restart your application pools. Microsoft added internal mitigations to both Kestrel and the HTTP.sys driver used by IIS. These changes include tighter stream accounting and faster cleanup of cancelled requests.

#Hardening Kestrel Configuration

Even after patching, explicitly configure lower limits for HTTP/2 streams. The defaults may still allow too many concurrent streams for high-security environments. Add the following to your Program.cs or Startup.cs to enforce stricter controls.

csharp 
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.Http2.MaxStreamsPerConnection = 32;
    serverOptions.Limits.Http2.InitialConnectionWindowSize = 65536;
    serverOptions.Limits.Http2.InitialStreamWindowSize = 32768;
});

var app = builder.Build();

#Adding Rate Limiting Middleware

Rate limiting at the application layer catches attacks that slip past the protocol stack. The built-in RateLimiter in ASP.NET Core lets you define policies based on IP address, user identity, or custom logic. Here is a fixed-window implementation suitable for most public APIs.

csharp 
builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    options.AddPolicy("ip", httpContext =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown",
            factory: _ => new FixedWindowRateLimiterOptions
            {
                AutoReplenishment = true,
                PermitLimit = 100,
                QueueLimit = 0,
                Window = TimeSpan.FromSeconds(15)
            }));
});

// Later in the pipeline:
app.UseRateLimiter();

#Ongoing Monitoring and Response

  • Enable detailed HTTP logging and monitor for high volumes of 400-class responses or rapid connection closures
  • Integrate Application Insights or your preferred telemetry to alert on spikes in request cancellation rates
  • Consider a Web Application Firewall rule that throttles connections exhibiting high reset ratios
  • Regularly test your mitigations using open-source HTTP/2 attack tools in a non-production environment

Takeaway: Protocol vulnerabilities like CVE-2023-44487 demonstrate that web platform security requires constant vigilance at every layer. Update your .NET and Windows components without delay, apply the configuration limits shown above, and maintain active monitoring. These practices will protect your sites not only from this specific CVE but from the next wave of similar threats. Schedule a review of all production applications this week to confirm they meet the hardened baseline.