CVE-2026-88092 & CVE-2026-70188: Critical Kestrel Vulnerabilities in .NET 6

Kestrel Vulnerabilities Overview

Microsoft has disclosed two critical vulnerabilities in Kestrel, the web server built into every ASP.NET Core application. Both can be triggered remotely, with no login and no user interaction. HeroDevs has already fixed both in Never-Ending Support (NES) for .NET 6, with release 6.0.47.

Both vulnerabilities live in Kestrel's core server library, which ships inside the shared ASP.NET Core runtime, on Windows, Linux, and macOS. Because .NET 6 has reached end of life, NES extended support is how .NET 6 applications receive these fixes. HeroDevs confirmed that unpatched .NET 6 is affected by both.

Affected .NET 6 versions: 6.0.0 through 6.0.46.

Fixed in: NES for .NET 6, release 6.0.47.

CVE-2026-88092: HTTP/1 request smuggling

An attacker can hide a second HTTP request inside the body of the first, and Kestrel will run it.

On a keep-alive connection, Kestrel normally discards any request body the app didn't read before moving on to the next request. When the connection was aborted mid-body, Kestrel skipped that cleanup but kept the connection's request loop running. The leftover body bytes were then parsed as a brand-new request.

In practice, a POST whose body contains a complete GET can make the application see two requests. Anything sitting in front of Kestrel only ever saw one.

CVE-2026-88092 is reachable on any Kestrel server speaking HTTP/1 with default settings. Microsoft lists ASP.NET Core 8.0, 9.0, 10.0 and the 11.0 previews as affected. HeroDevs confirmed .NET 6 carries the same code path.

CVE-2026-70188: newline injection in HTTP/2 trailers

Kestrel let carriage-return and line-feed characters slip through in HTTP/2 and HTTP/3 request trailers, the headers a client can send after the request body. The HTTP/2 spec says such values are malformed and must be rejected. In .NET 6, Kestrel already rejected these characters in regular headers but not in trailers, so trailers are the .NET 6 exposure.

Microsoft classifies it as a security feature bypass and has fixed it for its currently supported .NET versions.

Since .NET 6 is past end-of-life, HeroDevs engineers reviewed the .NET 6 source themselves and found the same trailer path, confirming .NET 6 is affected too.

Why CVE-2026-88092 and CVE-2026-70188 are critical

Both CVEs score above 9.0 because an attacker needs nothing but a network connection.

Both vectors share the same worst-case profile:

CVE-2026-88092 adds a Low availability impact, which lifts it to 9.4.

Kestrel is not an optional component. It is the default server for ASP.NET Core and commonly runs behind reverse proxies such as NGINX, YARP and cloud load balancers. Request smuggling is reachable on any HTTP/1 endpoint with default settings, and the trailer flaw is reachable on any endpoint that accepts HTTP/2 (and HTTP/3 where enabled).

Is my .NET 6 app affected?

You are exposed if you run an ASP.NET Core app on the .NET 6 shared runtime and are not on NES for .NET 6 release 6.0.47 or later.

Check the installed runtimes on each host or container:

dotnet --list-runtimes

Look for Microsoft.AspNetCore.App 6.0.x. Any version up to 6.0.36, the final Microsoft release, is vulnerable. NES customers on 6.0.37 through 6.0.46 should upgrade to 6.0.47.

To remediate, install NES for .NET 6 release 6.0.47.

Risks of running unpatched

Both flaws share the same core danger: your application processes something that the security layers in front of it never saw or never approved.

Request smuggling (CVE-2026-88092)

• Bypassing edge controls. A WAF, API gateway or proxy inspects the outer POST and approves it. The hidden GET reaches the app without ever being inspected, so path-based access rules, rate limits and filtering can be sidestepped.
• Reaching internal-only routes. Admin or health endpoints that a proxy blocks from the internet can be requested from inside an allowed request.
• Cross-user interference. If a proxy reuses backend connections, a desynchronized connection can cause one user's request or response to be mixed up with another's, risking data exposure or cache poisoning.

In plain terms: it's like a mailroom where security checks every envelope, but someone slips a second letter inside. Security approves the envelope, and the hidden letter goes straight to the CEO's desk unchecked.

Trailer newline injection (CVE-2026-70188)

• Bypassing validation. Malformed trailer values with embedded line breaks reach application code that assumes they were validated.
• Header and log injection. Values containing CR/LF can forge extra header lines or log entries if the app copies them into outbound requests, responses or logs.

In plain terms: it's like a visitor writing their name on a building's sign-in sheet, then adding a second line that reads "Approved by Security." Whoever reads the sheet later sees what looks like an official approval.

Now that fixes are public for supported .NET versions, attackers can compare patched and unpatched code to see exactly what changed. Runtimes that never receive the fix become the easiest targets, and every .NET 6 deployment without extended support falls into that group.

What HeroDevs did

HeroDevs fixed both vulnerabilities in NES for .NET 6 and verified the fixes against real attack traffic. Here's how.

We went straight to the .NET 6 source. Our engineers reviewed the .NET 6 source for each of these CVEs. That's how we confirmed both CVEs affect .NET 6, and exactly which parts of the upstream fix apply to it.

We kept the fixes surgical. Each patch is a minimal change to Kestrel's request handling, closely matching upstream’s fix for supported versions. No unrelated changes, no new behavior for well-formed traffic. Your application keeps working exactly as it did.

We proved the fix works, and that the vulnerability was real. For each CVE we replicated upstream security tests to .NET 6 and confirmed they failed without the fix and passed with it. Then we went further and attacked a live Kestrel server running both unpatched .NET 6 and NES for .NET 6:

Those attacks ran against the finished runtime on Linux, in containers and on Windows, so the protection is confirmed in what customers actually install.

We hardened the test suite too. While testing, our team made several of Kestrel's HTTP/2 tests more robust against timing issues, so future verification is more reliable.

Is .NET 8 affected?

These flaws also affect .NET 8, which Microsoft is patching while .NET 8 remains in support. That support ends on November 10, 2026. After that date, NES for .NET 8 continues to deliver security fixes like these, so .NET 8 teams keep the same coverage with no forced migration deadline.

Stay secure on .NET 6 with NES

.NET 6 may be end-of-life, but the applications built on it are not. NES for .NET gives you continued security fixes for .NET 6 and .NET 8, built and verified by engineers who read the code, so you can keep running in production while you plan your upgrade on your own schedule.

Learn more about NES for .NET