Microsoft released guidance in mid-June 2026 concerning a resource-exhaustion condition in Kestrel's HTTP/2 frame parser. Under specific traffic patterns an unauthenticated remote attacker can trigger excessive memory allocation, leading to worker process termination. The flaw exists in the current shipping branch of ASP.NET Core and in the .NET 10 runtime used by most production deployments.

Sites running behind IIS with the ASP.NET Core module or using Kestrel directly are both exposed. The advisory does not require a new CVE because it was handled through coordinated disclosure, but the practical impact matches prior high-severity DoS issues. Immediate mitigation is available through a configuration change plus the June 2026 cumulative update.

#Scope of Affected Deployments

Any application targeting .NET 10 or ASP.NET Core 10.0 that accepts untrusted HTTP/2 traffic is potentially affected. Self-hosted Kestrel instances and IIS-hosted sites using the in-process hosting model share the same vulnerable code path. Out-of-process hosting reduces blast radius but does not eliminate the risk.

  • Minimum impacted runtime: .NET 10.0.0
  • Minimum impacted ASP.NET Core package: 10.0.0
  • Hosting models: Kestrel direct, IIS in-process, IIS out-of-process

#Immediate Configuration Hardening

Until the June cumulative update is applied, limit the number of HTTP/2 streams and header size to reduce attack surface. Add the following settings in Program.cs or via appsettings.json.

csharp 
builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxRequestHeaderCount = 50;
    options.Limits.MaxRequestHeadersTotalSize = 32 * 1024;
    options.Limits.Http2.MaxStreamsPerConnection = 100;
});

#Apply the June 2026 Update

Install the latest .NET 10 and ASP.NET Core 10 servicing release published on 9 June 2026. On Windows Server, run Windows Update or download the standalone installer. After installation, recycle application pools or restart Kestrel processes.

bash 
dotnet --list-sdks
dotnet --list-runtimes

#Validation Steps

After patching, confirm the runtime version and test header limits with a simple load script. Monitor worker process memory under synthetic HTTP/2 flood traffic to verify the configuration change is effective.

Apply the configuration limits today, schedule the runtime update within the next maintenance window, and re-test your load balancer and WAF rules. These two actions close the exposure for the overwhelming majority of production ASP.NET Core sites.