ASP.NET Security Feature Bypass Vulnerability

This appears to be the code change: https://github.com/dotnet/aspnetcore/commit/97a86434195a82fc...

This is a dumb way of scoring the bug.

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

It's actually "ASP .NET Core", which can run on .NET Framework.

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.

There is no .NET Core or .NET Framework since .NET 5.0 in 2020. Maybe you mean ASP.NET Core, but then there is no ASP.NET Framework so the comment still does not make sense to me.

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.

Or you could say that this affects "recent versions of .NET". The "core" qualifier has largely been dropped now.

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

would you rather have a nonsensical 10 for redis instead?

This only works when deploying the application as framework-dependent, right? I think applications that use self-contained deployment still need to be rebuilt (after updating dev tools) and redeployed.

No different to using RHEL OpenJDK on Linux and running `dnf update`

Who doesn't use containers these days to deploy web apps?

> You often don't have to rebuild or redeploy your software if you are using the included batteries as intended

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.

Yes agreed, applying updates is very easy and pain free these days.

The GH issue mentions POTENTIAL risks, looked at the patch and I can see 2 scenarios:

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.

I mean it will now it's gone to the front of HN ;)

Yes, because every one of our customers will be emailing me today with a questionnaire:

* 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.)

I certainly did; I'm also not trusting the `Less likely to be exploited` rating, but since updating is easy in most cases, why not?

Actually, I think that a proxy might be a worse scenario in terms of exploitability.

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

I don't remember exactly when, but I'm sure I recall Kestrel being declared production ready a few years back.

The fix was released 14 October 2025, in the "patch Tuesday" release. There are links to the fix code change in these threads, and a sufficiently determined person could work from that to find the vulnerability. So any embargo is likely expiring now.