ASP.NET Core EUVD-2026-100147

The flaw is in Microsoft.AspNetCore.Server.Kestrel.Core and triggers specifically when a Kestrel HTTP/1 connection is aborted with unread request-body bytes remaining, which Kestrel then reparses as a new request (a request-smuggling/desync condition). The exact prerequisite is use of the Kestrel HTTP/1 server in an affected runtime (ASP.NET Core 8.0 <8.0.32, 9.0 <9.0.21, 10.0 <10.0.13, 11.0 <11.0.0-rc.2). Exploitation requires no authentication or user interaction (PR:N/UI:N). Realistic impact is amplified when the application sits behind a shared front-end proxy, load balancer, or uses connection keep-alive/pooling, since smuggled requests can affect other clients; a single-tenant, directly-exposed instance with no shared connection reuse limits the practical tampering surface.

This is a genuine high-priority issue, not a CVSS-inflated one. The vendor-assigned CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a remote, low-complexity, unauthenticated attack, and the 9.4 Critical score is corroborated directly by Microsoft/MSRC and the dotnet/aspnetcore GHSA advisory (GHSA-rv87-ccxw-8ggf). The SSVC framework reinforces severity on two axes - Automatable: yes and Technical Impact: total - meaning exploitation could be reliably scripted once a technique exists. The one tempering signal is SSVC Exploitation: none, and there is no CISA KEV listing and no public POC in the provided data, so active exploitation is NOT confirmed. The practical result: high theoretical exploitability and impact against a hugely deployed framework, but no evidence yet of real-world attacks - a strong candidate for prompt patching rather than emergency incident response. Note one point to verify: CWE-444 smuggling frequently crosses a trust boundary into a back-end system (arguably a scope change), yet the vendor rated S:U; defenders behind shared proxies/load balancers should treat the blast radius as potentially larger than S:U implies.

An attacker sends a crafted HTTP/1 request to a Kestrel-fronted ASP.NET Core application and then aborts the connection, leaving unread request-body bytes that Kestrel reparses as a separate, smuggled request. By desynchronizing the server's view of the request stream, the attacker can poison request queuing on shared/keep-alive connections to tamper with or bypass security controls affecting other users' requests. No public exploit code is identified at time of analysis, so this remains a theoretical-but-credible path.