Microsoft released guidance in early 2026 on improper handling of certain malformed HTTP/2 frames in Kestrel. Sites running ASP.NET Core on Windows Server with default Kestrel configuration face elevated risk of request smuggling and resource exhaustion under sustained attack.

The core issue stems from insufficient validation of continuation frames when HTTP/2 is enabled. Attackers who control a client connection can craft sequences that bypass normal limits, leading to unexpected request processing or memory pressure.

Immediate steps include enforcing the latest .NET 10 servicing release, tightening Kestrel limits, and placing IIS in front of Kestrel with strict request filtering. These changes close the exposure without requiring code changes in most applications.

#Scope of Affected Deployments

  • ASP.NET Core 9 and 10 applications using the default Kestrel server with HTTP/2 enabled
  • Self-hosted or container deployments without an intervening reverse proxy
  • Sites accepting untrusted client connections directly on port 443 or 80

#Configuration Hardening

Add explicit limits in Program.cs or the Kestrel options section of appsettings.json. The following settings cap frame sizes and concurrent streams to values proven safe against the reported vectors.

csharp 
builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.Http2.MaxFrameSize = 16384;
    options.Limits.Http2.MaxStreamsPerConnection = 100;
    options.Limits.MaxRequestBodySize = 10485760;
});

When running behind IIS, ensure the Application Request Routing module and URL Rewrite rules reject requests exceeding 16 KB headers before they reach Kestrel.

#Verification and Monitoring

  • Run dotnet --list-sdks and confirm the June 2026 or newer patch level is installed
  • Enable Kestrel event logging at Information level and alert on Http2FrameSizeLimitExceeded
  • Use load testing tools to replay crafted HTTP/2 sequences in a staging environment

#Ongoing Maintenance

Subscribe to the Microsoft Security Response Center RSS feed and apply .NET patches within seven days of release. Review Kestrel configuration after each major .NET update because default limits can change.

Apply these controls today. Updated Kestrel settings combined with current .NET binaries eliminate the reported exposure on production Windows Server hosts.