[.NET] CVE-2026-88092: Kestrel Request Smuggling Fix

 

CVE-2026-88092 is a request-smuggling flaw in Kestrel, the web server built into ASP.NET Core. If your app runs on .NET 8, 9, or 10, update the runtime to 8.0.32, 9.0.21, or 10.0.13 or later, then restart the app. It scores 9.4 on CVSS 3.1 (Critical).

 

When Kestrel aborts an HTTP/1 connection, it can read leftover request-body bytes as a brand-new request. Behind a reverse proxy, that can let an attacker slip in an unintended request. This post draws on Microsoft's .NET advisory (dotnet/announcements #472), the Microsoft Security Response Center (MSRC) page, the GitHub advisory, and the October release notes.

 

Read in other languages: 한국어 · 日本語 · Tiếng Việt

 

 

At a glance

Here's what Microsoft has published so far.

 

As of October 28, 2026, based on .NET advisory #472 and the MSRC page.

 

Item	Details
Published	October 13, 2026 (Patch Tuesday)
Component	Kestrel (ASP.NET Core web server)
Weakness	CWE-444, HTTP request smuggling
Score	CVSS 3.1: 9.4 (Critical)
MSRC rating	Important, Tampering
Attack needs	No sign-in, no user interaction
Affected	.NET 8, 9, and 10; .NET 11 up to RC1
Exploited?	Not disclosed or exploited
Fix	Update the runtime, restart apps

 

The advisory names the component as Microsoft.AspNetCore.Server.Kestrel.Core, and Microsoft credits thegoldmandm with reporting the flaw. Of the 46 .NET security advisories published on October 13, this one has the second-highest score overall and the highest among those with "ASP.NET Core" in the title.

 

 

What the flaw is

HTTP/1.1 lets one connection carry several requests in a row. To find where the next request starts, a server has to know where the previous request's body ends. When a proxy and the server behind it disagree on that boundary, an attacker can hide an extra request in the stream. That's HTTP request smuggling.

 

Kestrel's bug, per the advisory, is in how it cleans up. If it aborts an HTTP/1 connection while part of the request body is still unread, those leftover bytes can end up parsed as a second request. Data that belonged to the first request's body becomes a new one.

 

What happens behind a reverse proxy (concept)

1

Crafted request

An attacker with no account sends a specially built HTTP/1.1 request that travels via the reverse proxy

2

The proxy forwards it

The proxy passes the request to Kestrel as usual

3

Kestrel aborts the connection

Processing ends while body bytes are still unread

4

Boundaries fall out of sync

The leftover bytes are parsed as a new request, so an unintended request can slip in

Source: .NET security advisory #472, MSRC FAQ

 

MSRC's FAQ names the attack path: requests that travel through a reverse proxy to an affected server. The attacker needs no account, and nobody has to click anything. A crafted HTTP/1.1 request can leave the proxy and Kestrel disagreeing about where one request ends and the next begins, and that gap is what lets an unintended request in.

 

In general, request smuggling is dangerous because an injected request can get past checks the proxy would otherwise apply. The .NET advisory classifies this flaw as a security feature bypass, MSRC calls it tampering, and both rate confidentiality and integrity impact as High. Neither describes a specific bypass or damage.

 

 

Are you affected?

The ASP.NET Core runtime in .NET 8, 9, and 10, plus .NET 11 preview and RC1 builds, is affected. The advisory names Kestrel, and MSRC describes the attack path as a server behind a reverse proxy.

 

What to check by deployment type

Kestrel behind a proxy Attack path

Apps where Kestrel takes requests behind a reverse proxy such as NGINX, YARP, or IIS out-of-process

To do

Update runtimeRestart

MSRC only says 'reverse proxy.' The product names are examples

Self-contained apps Bundled runtime

Apps that ship their own runtime, and container images

To do

RepublishRebuild image

Updating the server runtime doesn't change them

Not stated in the advisory Impact not stated

ASP.NET Core 2.3 on .NET Framework isn't on the list. The advisory doesn't say whether IIS in-process or HTTP.sys is affected

To do

Same runtime update if on an affected version

The advisory's list is organized by runtime version and doesn't mention hosting models

Source: .NET security advisory #472, MSRC, Microsoft Learn

 

Affected and fixed runtime versions, per the advisory:

 

Line	Affected	Fixed
.NET 8	8.0.0 to 8.0.31	8.0.32 (SDK 8.0.426)
.NET 9	9.0.0 to 9.0.20	9.0.21 (SDK 9.0.319)
.NET 10	10.0.0 to 10.0.12	10.0.13 (SDK 10.0.402)
.NET 11	preview.1 to RC1	RC2

 

• IIS in-process hosting: Microsoft Learn says in-process hosting uses IIS HTTP Server instead of Kestrel, and it has been the IIS default since ASP.NET Core 3.0. The advisory doesn't say whether IIS HTTP Server is affected, though. The update covers the whole shared runtime, so apply it whichever server you use
• ASP.NET Core 2.3: the .NET Framework flavor isn't on this list
• Visual Studio: the MSRC table also lists Visual Studio 2022 (17.14.42) and 2026 (18.10.4). The advisory says SDKs installed through Visual Studio are updated by updating Visual Studio

 

반응형

 

How to update

The advisory asks you to install the latest .NET runtime or SDK and restart your apps. Self-contained apps must be recompiled and redeployed.

 

# List the ASP.NET Core runtimes installed on a server
dotnet --list-runtimes
# Fixed: 8.0.32 / 9.0.21 / 10.0.13 or later

# Self-contained apps: republish with the updated SDK
dotnet publish -c Release -r linux-x64 --self-contained

 

1. Update the runtime and SDK on app servers and build machines. On IIS servers, use the Hosting Bundle, which installs the .NET runtime and the ASP.NET Core Module. As of October 28, 2026, the latest downloads are the October 25 out-of-band releases (8.0.33, 9.0.22, 10.0.14). They're above the advisory's affected ranges (8.0.31, 9.0.20, 10.0.12 and earlier)
2. Restart your apps: the advisory says the update takes effect after a restart. A running process keeps using the old runtime
3. Self-contained apps and containers: per Microsoft Learn, a self-contained publish bundles the latest runtime patch that the SDK on the publishing machine has. Republish with the new SDK, and update RuntimeFrameworkVersion if you pinned it. For containers, pull a fresh mcr.microsoft.com/dotnet/aspnet base image and rebuild

 

The advisory lists packages named Microsoft.AspNetCore.App.Runtime.<platform>. Those are runtime packs that go into self-contained builds. The advisory also says that if your project references a runtime pack directly, you should update that reference to the patched version. Search your .csproj files for Microsoft.AspNetCore.App.Runtime to check; if there's no match, the three steps above are enough.

 

Neither the advisory nor MSRC offers a configuration workaround. If you can't patch everything at once, start with internet-facing Kestrel apps behind a proxy. That's a way to set priorities, not an official mitigation.

 

 

Has it been exploited?

As of its first publication, MSRC lists the CVE as not publicly disclosed and not exploited, with an exploitability assessment of "Exploitation Less Likely." The temporal metrics read Unproven exploit code (E:U) and Official Fix (RL:O), for a temporal score of 8.2.

 

The base score is still 9.4 because the attack works over the network, needs no sign-in or user interaction, and can cause serious confidentiality and integrity damage. Internet-facing services should be patched first, whatever the exploitability rating says.

 

 

What US teams should check

Two things are specific to US teams: what the government records say, and who patches the runtime on your cloud.

 

US government records. As of October 28, 2026, NVD lists the record as "Analyzed" (last modified October 16), showing the 9.4 score Microsoft submitted. The CVE record was last updated October 27, and CISA's SSVC entry in it shows exploitation "none," automatable "yes," and technical impact "total."

 

Those are CISA's triage labels, not a sign of active attacks. We didn't see the CVE in CISA's Known Exploited Vulnerabilities (KEV) catalog (version 2026.10.27). None of that means you can skip the update.

 

Who patches the runtime depends on where you host:

 

• Azure App Service: Microsoft Learn says App Service applies .NET runtime patch updates automatically. The App Service team's October 26 posts cover the October 25 release (10.0.14), which is above the affected range and doesn't mention this CVE. As of that date, the 10.0.14 rollout was complete on the Linux Latest channel and still in progress on Standard and on Windows. Self-contained apps and custom containers are yours to rebuild
• AWS Elastic Beanstalk: the .NET on Amazon Linux 2023 platform shipped 8.0.32, 9.0.21, and 10.0.13 on October 20, and 8.0.33, 9.0.22, and 10.0.14 on October 27. If you've turned on managed platform updates, Elastic Beanstalk applies them in your weekly maintenance window. Otherwise, update the environment's platform version yourself
• Amazon Linux 2023: Amazon's security page for this CVE marks the dotnet8.0, dotnet9.0, and dotnet10.0 packages "Fixed" and dotnet6.0 "No Fix Planned." Microsoft's advisory doesn't list .NET 6 at all
• Azure Container Apps, AKS, Web App for Containers: Azure's architecture guidance lists container image updates as the customer's job. Rebuild on a patched base image

 

Check, don't assume. On App Service, Microsoft Learn suggests running dotnet --version in the Kudu console. Anywhere else, use dotnet --list-runtimes or dotnet --info.

 

 

Common misconceptions

• It has two names: the .NET advisory and release notes call it "Security Feature Bypass," while MSRC and the CVE record call it "Tampering." Same bug
• It has two severity labels: Critical by CVSS 3.1 (9.4), Important by MSRC's own rating. Same flaw, different scales
• It isn't last year's CVE-2025-55315: October 2025 brought a separate ASP.NET Core request-smuggling advisory (CVSS 9.9) that also covered ASP.NET Core 2.3. This one has a new ID and doesn't include 2.3
• It's usually a runtime update, not a package update: the Blazor debugger flaw from the same release (CVE-2026-102870) required updating NuGet packages. Here, Kestrel ships in the shared runtime, so updating and restarting is enough, except for self-contained apps
• You don't need the October 25 release for this one: unlike CVE-2026-102870, this CVE isn't listed in the out-of-band release, and advisory #472 is still at V1.0. The October 25 releases are above the affected range too, so they work as well

 

반응형

 

FAQ

Short answers to four common questions.

 

What is CVE-2026-88092?

CVE-2026-88092 is a Kestrel flaw in ASP.NET Core. When an HTTP/1 connection is aborted, unread request-body bytes can be parsed as a new request. The reverse proxy and the server then disagree on request boundaries, so an attacker can inject a request. The CVSS 3.1 score is 9.4.

 

Which version should I install?

Update the ASP.NET Core runtime to 8.0.32, 9.0.21, or 10.0.13 or later. For .NET 11 previews, use RC2 or later. The October 25 releases (8.0.33, 9.0.22, 10.0.14) are above those versions too.

 

Am I safe if I don't use a proxy?

MSRC describes the attack path as requests that pass through a reverse proxy. The advisory doesn't say setups without a proxy are out of scope, though. If you're on an affected version, update regardless.

 

Do I need to update NuGet packages?

Usually not. The packages in the advisory are runtime packs used for self-contained deployment, so updating the runtime on your servers and restarting is enough. If a .csproj references a Microsoft.AspNetCore.App.Runtime.* package directly, though, update that reference to the patched version.

 

 

Summary

• CVE-2026-88092 makes Kestrel read leftover body bytes from an aborted HTTP/1 connection as a new request, enabling request smuggling behind a reverse proxy
• It scores CVSS 9.4, near the top of October's .NET advisories, with no exploitation reported
• Update the ASP.NET Core runtime to 8.0.32, 9.0.21, or 10.0.13 or later and restart. Rebuild self-contained apps and containers

 

References

• .NET security advisory #472: CVE-2026-88092
• MSRC: CVE-2026-88092 ASP.NET Core Tampering Vulnerability
• GitHub security advisory GHSA-rv87-ccxw-8ggf (.NET repo)
• .NET 10.0.13 release notes
• .NET October 2026 out-of-band security updates #496
• NVD: CVE-2026-88092
• CVE Record: CVE-2026-88092 (includes CISA ADP SSVC)
• CISA Known Exploited Vulnerabilities Catalog
• Amazon Linux Security Center: CVE-2026-88092
• AWS Elastic Beanstalk release notes, October 20, 2026
• AWS Elastic Beanstalk release notes, October 27, 2026
• Microsoft Learn: OS and runtime patching in Azure App Service
• Azure App Service team blog: .NET security update on App Service Linux (October 26)
• Azure App Service team blog: .NET security update on App Service Windows (October 26)
• Azure Architecture Center: Choosing an Azure container service
• Microsoft Learn: Hosting Bundle
• Microsoft Learn: In-process hosting with IIS and ASP.NET Core
• Microsoft Learn: Runtime roll forward for self-contained deployments
• GitHub Advisory Database: CVE-2025-55315 (GHSA-5rrx-jjjq-q2r5)

 

Related posts

• [.NET] CVE-2026-102870: Blazor Debugger Fix Wasn't Enough — Same October .NET release, but that Blazor flaw needs a package update, not just a runtime update