Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 4 min read

CVE-2026-114154: CVE-2026-114154: Denial of Service in ASP.NET Core HttpSys Request Header Processing

CVE-2026-114154: Denial of Service in ASP.NET Core HttpSys Request Header Processing Vulnerability ID: CVE-2026-114154 CVSS Score: 7.5 Published: 2026-11-11 CVE-2026-114154 is a high-severity Denial of Service (DoS)

CVE-2026-114154: Denial of Service in ASP.NET Core HttpSys Request Header Processing

Vulnerability ID: CVE-2026-114154
CVSS Score: 7.5
Published: 2026-11-11

CVE-2026-114154 is a high-severity Denial of Service (DoS) and uncontrolled resource consumption vulnerability in the Microsoft.AspNetCore.Server.HttpSys component of ASP.NET Core. When processing an HTTP request that simultaneously contains a chunked Transfer-Encoding header, a Content-Length header, and an explicit X-Content-Length header, the server throws an unhandled ArgumentException during header normalization. In certain versions, subsequent exception handling attempts to dereference a disposed native request context, aborting error response dispatch and leaking unmanaged HTTP.sys request structures.

TL;DR

An unauthenticated remote attacker can trigger a Denial of Service in ASP.NET Core applications hosted on Windows HTTP.sys by sending a single crafted HTTP request containing Transfer-Encoding: chunked, Content-Length, and X-Content-Length headers simultaneously.

Technical Details

  • CWE ID: CWE-401 (Missing Release of Memory after Effective Lifetime)
  • CVSS v3.1 Score: 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
  • Attack Vector: Network (Unauthenticated HTTP/1.1 Request)
  • Affected Component: Microsoft.AspNetCore.Server.HttpSys
  • Primary Impact: Denial of Service via Unhandled Exception & Native Resource Leak
  • Exploit Status: Unproven (No Public Weaponized Exploits)
  • CISA KEV Status: Not Listed

Affected Systems

  • Microsoft.AspNetCore.Server.HttpSys
  • ASP.NET Core (.NET 8.0, .NET 9.0, .NET 10.0)
  • Microsoft Visual Studio 2022 version 17.14
  • Microsoft Visual Studio 2026 version 18.11
  • Microsoft Visual Studio 2026 version 18.12
  • Microsoft.AspNetCore.Server.HttpSys: >= 2.3.10, < 2.3.14 (Fixed in: 2.3.14)
  • .NET 8.0: >= 8.0.0, < 8.0.34 (Fixed in: 8.0.34)
  • .NET 9.0: >= 9.0.0, < 9.0.23 (Fixed in: 9.0.23)
  • .NET 10.0: >= 10.0.0, < 10.0.15 (Fixed in: 10.0.15)
  • Microsoft Visual Studio 2022 version 17.14: >= 17.14.0, < 17.14.45 (Fixed in: 17.14.45)
  • Microsoft Visual Studio 2026 version 18.11: >= 18.11.0, < 18.11.4 (Fixed in: 18.11.4)
  • Microsoft Visual Studio 2026 version 18.12: 18.12.0 (Fixed in: 18.12.1)

Code Analysis

Commit: 20e629e

Use TryAdd when setting X-Content-Length in HttpSys Request.cs (release/9.0 - PR 65561)

File: src/Servers/HttpSys/src/RequestProcessing/Request.cs
@@ -522,7 +522,9 @@ private void RemoveContentLengthIfTransferEncodingContainsChunked()
         // We should remove the Content-Length request header in this case, for compatibility
         // reasons, include x-Content-Length so that the original Content-Length is still available.
         IHeaderDictionary headerDictionary = Headers;
-        headerDictionary.Add("X-Content-Length", headerDictionary[HeaderNames.ContentLength]);
+
+        // if user already passed X-Content-Length, we won't overwrite it
+        headerDictionary.TryAdd("X-Content-Length", headerDictionary[HeaderNames.ContentLength]);
         Headers.ContentLength = StringValues.Empty;

         if (!AllowKeepAliveAfterCLTE)

Commit: 8cb8dc4

Use TryAdd when setting X-Content-Length in HttpSys Request.cs (release/8.0 - PR 65559)

File: src/Servers/HttpSys/src/RequestProcessing/Request.cs
@@ -522,7 +522,9 @@ private void RemoveContentLengthIfTransferEncodingContainsChunked()
         // We should remove the Content-Length request header in this case, for compatibility
         // reasons, include x-Content-Length so that the original Content-Length is still available.
         IHeaderDictionary headerDictionary = Headers;
-        headerDictionary.Add("X-Content-Length", headerDictionary[HeaderNames.ContentLength]);
+
+        // if user already passed X-Content-Length, we won't overwrite it
+        headerDictionary.TryAdd("X-Content-Length", headerDictionary[HeaderNames.ContentLength]);
         Headers.ContentLength = StringValues.Empty;

         if (!AllowKeepAliveAfterCLTE)

Commit: efc799e

Cache RequestId before try block in AsyncAcceptContext and check ContainsKey for X-Content-Length in Request.cs (release/2.3 - PR 65343)

File: src/Servers/HttpSys/src/AsyncAcceptContext.cs
@@ -70,6 +70,8 @@ private static void IOCompleted(AsyncAcceptContext asyncResult, uint errorCode,
                     HttpSysListener server = asyncResult.Server;
                     if (errorCode == UnsafeNclNativeMethods.ErrorCodes.ERROR_SUCCESS)
                     {
+                        var requestId = asyncResult._nativeRequestContext.RequestId;
+
                         // at this point we have received an unmanaged HTTP_REQUEST and memoryBlob
                         // points to it we need to hook up our authentication handling code here.
                         try
@@ -83,7 +85,7 @@ private static void IOCompleted(AsyncAcceptContext asyncResult, uint errorCode,
                         }
                         catch (Exception)
                         {
-                            server.SendError(asyncResult._nativeRequestContext.RequestId, StatusCodes.Status400BadRequest);
+                            server.SendError(requestId, StatusCodes.Status400BadRequest);
                             throw;
                         }
                         finally

File: src/Servers/HttpSys/src/RequestProcessing/Request.cs
@@ -380,7 +380,12 @@ private void RemoveContentLengthIfTransferEncodingContainsChunked()
             // We should remove the Content-Length request header in this case, for compatibility
             // reasons, include x-Content-Length so that the original Content-Length is still available.
             IHeaderDictionary headerDictionary = Headers;
-            headerDictionary.Add("X-Content-Length", headerDictionary[HttpKnownHeaderNames.ContentLength]);
+
+            // if user already passed X-Content-Length, we won't overwrite it
+            if (!headerDictionary.ContainsKey("X-Content-Length"))
+            {
+                headerDictionary.Add("X-Content-Length", headerDictionary[HttpKnownHeaderNames.ContentLength]);
+            }
             Headers.ContentLength = StringValues.Empty;

             if (!AllowKeepAliveAfterCLTE)

Mitigation Strategies

  • Upgrade .NET Runtime and ASP.NET Core shared frameworks to the latest patched versions (8.0.34, 9.0.23, or 10.0.15).
  • Update the standalone Microsoft.AspNetCore.Server.HttpSys NuGet package to version 2.3.14 or later.
  • Configure upstream WAFs, load balancers, or reverse proxies to drop HTTP requests containing both Transfer-Encoding and Content-Length headers.
  • Strip client-supplied X-Content-Length headers at network edge proxies prior to forwarding traffic to backend HttpSys servers.

Remediation Steps:

  1. Identify all Windows hosts running ASP.NET Core applications configured with UseHttpSys() or referencing Microsoft.AspNetCore.Server.HttpSys.
  2. Install the patched .NET Hosting Bundle / Runtime (8.0.34+, 9.0.23+, or 10.0.15+) on affected Windows servers and restart the hosting services.
  3. For self-contained deployments or projects referencing Microsoft.AspNetCore.Server.HttpSys 2.3.x, update the package reference to 2.3.14, rebuild, and redeploy the application.
  4. Verify the fix by sending a test request containing Transfer-Encoding: chunked, Content-Length, and X-Content-Length headers and confirming the server handles the request without throwing an unhandled exception.

References

Read the full report for CVE-2026-114154 on our website for more details including interactive diagrams and full exploit analysis.

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.