The vulnerable component is ASP.NET Core, which did not change name when .NET dropped the Core name to distinguish it from legacy ASP.NET.

--- edit: cut here - the sentence below is incorrect! ---

If somehow you were still using legacy ASP.NET / Framework 4.8 etc, you have much bigger problems - legacy ASP.NET has been unsupported since 2022 so will definitely not be receiving security updates.

That started in .NET 5.0 in November 2020, which was nearly 5 years ago now.

Listed as affected at the top in the github post is ASP .NET Core 2.3

ASP .NET Core 2.3 is a .NET Framework package, as explained by https://devblogs.microsoft.com/dotnet/servicing-release-advi...

It was released in February 2025, for those who think framework isn't supported.

* Are we affected?

* What’s our timeline for fixing this?

* Have we asked all of our vendors the same questions?

(This doesn’t affect us in any way. If it did, I’d be scrambling to patch it so that our customers would relax.)

1: You have a load-balancer infront that handles authentication somehow and then coalesces multiple incoming requests into single connections, one authenticated user's request can then somehow to be confused by the backend to the attackers that can then impersonate.

2: The .NET request pipeline seems to be meant to be fairly thin to enable performance, potentially you have some middleware for authentication that again gets fooled by this bug.

I think the high rating is that if it is found out that some popular application like Umbraco turns out to be vulnerable, then tons of targets will be viable and having them patch their servers before that is found out is beneficial.

The bug itself doesn't enable any of those. An app using the library might have that vuln.

Instead, your software's lifecycle is entirely dependent on the OS' lifecycle. That seems worse.

And for what it's worth, it would be exactly the same with any "interpreted"/VM-based language - Java and family friends, Python, Ruby, etc. Just update the VM/interpreter and restart (the service though, not the whole server).

It's for compiled languages like Go or C/C++ or Rust that you would need to recompile. I prefer it because it ensures the lifecycle only depends on you and you aren't bound by OS versions and OS updates to be able to update/downgrade library/framework/language versions.

If the proxy that handles authentication has one notion of chunked encoding and Kestrel behind it has another notion and the proxy then shares it's connection between users, then an attacker might smuggle in a request to a high value endpoint.

For example:

- Kestrel serves an application with the endpoints /public_get_stats and /admin/change_user_rights

- The proxy makes sure everything under /admin is authorized

- An attacker does a POST request to /public_get_stats , the post is sent with CHUNKED encoding that the proxy interprets in one way thus letting it be passed to Kestrel

- Kestrel behind it starts processing /public_get_stats but mis-interprets the chunked boundary leaving the parser to start the next (malicious) request, that in turn contains, a payload saying {"userid":"hacker","level":"superuser"} to /admin/change_user_rights