Microsoft released guidance in late May 2026 on improper validation of certain authentication headers in ASP.NET Core. The issue allows an attacker with network access to forge requests that bypass standard JWT checks when the application runs behind IIS with specific module configurations.

Sites running .NET 9 and earlier are affected; the current .NET 10 release contains the corrected validation logic. Immediate patching and header normalization are required for any production deployment accepting bearer tokens.

The remainder of this post covers the root cause, affected configurations, and concrete steps to close the exposure on Windows Server hosts.

#Root Cause

The vulnerability stems from case-insensitive header merging performed by the IIS ASP.NET Core module before the request reaches Kestrel. When duplicate Authorization headers arrive with differing casing, the merged value can be misinterpreted by older JWT handlers.

#Who Is Affected

  • Applications targeting .NET 9 or earlier that use Microsoft.AspNetCore.Authentication.JwtBearer
  • Deployments behind IIS 10 with the ASP.NET Core module version 9.x or lower
  • Sites that accept tokens from untrusted proxies without explicit header sanitization

#Immediate Mitigation

Upgrade the application to .NET 10 and the latest stable ASP.NET Core 10 packages. Rebuild and redeploy.

bash
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer --version 10.0.*

Add explicit header normalization middleware early in the pipeline.

csharp
app.Use(async (context, next) => {
    if (context.Request.Headers.TryGetValue("Authorization", out var auth))
    {
        context.Request.Headers["Authorization"] = auth.ToString().Trim();
    }
    await next();
});

#Additional Hardening

  • Disable automatic header merging in the IIS ASP.NET Core module via applicationHost.config
  • Enforce strict token audience and issuer validation in JwtBearerOptions
  • Run regular dependency scans with dotnet list package --vulnerable

Apply these changes, test token flows in staging, then deploy to production. Monitor authentication logs for malformed header attempts during the transition window.