ASP.NET Security Feature Bypass Vulnerability(nvd.nist.gov)
nvd.nist.gov
ASP.NET Security Feature Bypass Vulnerability
https://nvd.nist.gov/vuln/detail/CVE-2025-55315
56 comments
Interesting that they put it as 'Less likely to be exploited' but at the same time give it a 9.9 riskiness.
It sort of implies it will be quikcly under active investigation by hostile actors, and then get's raised to an urgent threat?
It sort of implies it will be quikcly under active investigation by hostile actors, and then get's raised to an urgent threat?
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.
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 ;)
Probably a better link: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
Isn't this only exploitable if you expose Kestrel to the internet? They (used to?) recommend to put a proxy in front of it so I would guess most deployments are done like that
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
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.
Yes, they definitely declared it production ready a while back. I use it bare metal exposed to the Internet and it works great. (TFA not withstanding)
Is this another instance of HTTP desync?
Yes, CWE-444, "Inconsistent interpretation of HTTP requests."
[deleted]
Note that this affects ".net core", not ".net framework"
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
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.
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.
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.
That started in .NET 5.0 in November 2020, which was nearly 5 years ago now.
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.
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.
> 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.
I don't think this is correct:
.NET 4.8 / 4.8.1 shows does not have an end of support date set: https://dotnet.microsoft.com/en-us/platform/support/policy/d...
Also ASP.NET MVC 5 does not have an end of support date set: https://dotnet.microsoft.com/en-us/platform/support/policy/a...
There are plenty of apps out there were there is no feasible upgrade path to .NET Core / .NET 9, so I imagine MS will continue to support these for a very long time. Note that the VB6 runtime is still supported in all Windows operating systems: https://learn.microsoft.com/en-us/previous-versions/visualst...
I don't think this is correct:
.NET 4.8 / 4.8.1 shows does not have an end of support date set: https://dotnet.microsoft.com/en-us/platform/support/policy/d...
Also ASP.NET MVC 5 does not have an end of support date set: https://dotnet.microsoft.com/en-us/platform/support/policy/a...
There are plenty of apps out there were there is no feasible upgrade path to .NET Core / .NET 9, so I imagine MS will continue to support these for a very long time. Note that the VB6 runtime is still supported in all Windows operating systems: https://learn.microsoft.com/en-us/previous-versions/visualst...
Yes, you're right, the last sentence is definitely a mistake on my part, I should have written less! Thanks for the links, paulirwin's sibling response is helpful too.
We had code using WCF and AppDomains that were always out of scope for .NET Core. WCF has a Core replacement now that is not quite one-for-one but AppDomains will never be supported in .NET Core / .NET 5.0+ and would indeed have to stay on 4.8 / 4.8.1 if they were still running.
We had code using WCF and AppDomains that were always out of scope for .NET Core. WCF has a Core replacement now that is not quite one-for-one but AppDomains will never be supported in .NET Core / .NET 5.0+ and would indeed have to stay on 4.8 / 4.8.1 if they were still running.
The last sentence is not correct. ASP.NET is part of .NET Framework which is still supported by nature of being included with Windows, and follows its support lifecycle. https://dotnet.microsoft.com/en-us/platform/support/policy/a...
This is, IMO, a bad thing, and Microsoft needs to break this chain at some point, at least for ASP.NET. But, it is still technically supported.
This is, IMO, a bad thing, and Microsoft needs to break this chain at some point, at least for ASP.NET. But, it is still technically supported.
There is still modern MS product (Dataverse) that requires to code plugins in .NET Framework 4.6.2: https://learn.microsoft.com/en-us/power-apps/developer/data-...
And there is currently no official other supported version supported like .NET Framework 4.8 or simply .NET
And there is currently no official other supported version supported like .NET Framework 4.8 or simply .NET
Yes, you are right, if you are on 5.0+, however the 4.x stuff is definitely out of support.
Sorry, I did not know they had actually brought non-Core ASP.NET forward into 5.0+, but it makes sense given how much of .NET Framework they continued support for and how much ASP.NET and Forms stuff is still around in enterprise with no budget for bringing it forward.
Totally agree with breaking the chain though, we moved to Core around 2.0 and never looked back, as an ecosystem it is so much better.
Sorry, I did not know they had actually brought non-Core ASP.NET forward into 5.0+, but it makes sense given how much of .NET Framework they continued support for and how much ASP.NET and Forms stuff is still around in enterprise with no budget for bringing it forward.
Totally agree with breaking the chain though, we moved to Core around 2.0 and never looked back, as an ecosystem it is so much better.
> however the 4.x stuff is definitely out of support [...] Sorry, I did not know they had actually brought non-Core ASP.NET forward into 5.0+
None of this is true, you've gotten yourself very confused. The only real change with .NET 5 was the "Core" name being dropped and the Mono runtime being merged in. .NET Framework 4.x is still around and is still fully supported for legacy applications.
None of this is true, you've gotten yourself very confused. The only real change with .NET 5 was the "Core" name being dropped and the Mono runtime being merged in. .NET Framework 4.x is still around and is still fully supported for legacy applications.
Yes, there is, because Microsoft naming sucks, and making the distiction between .NET Core and .NET Framework is the only way to actually explain modern .NET to most folks without background on .NET.
Additionally the mistake to rename .NET Core as .NET is the main reason many people still think .NET is Windows only.
Additionally the mistake to rename .NET Core as .NET is the main reason many people still think .NET is Windows only.
Well they did have a valid reason for a rename, .NET 5.0's announcement coincided with discontinuing Mono and Xamarin, and uniting the non-Windows .NET flavors under a single platform. They also planned to iterate more rapidly and add APIs beyond .NET Standard.
But yes, choosing ".NET" as the new name was a bad idea, since now when someone says .NET you have no idea if they are referring to the modern runtime, or its various generations collectively.
But yes, choosing ".NET" as the new name was a bad idea, since now when someone says .NET you have no idea if they are referring to the modern runtime, or its various generations collectively.
I, for one, think dropping the "Core" suffix (absolutely dumb naming) was the right thing. Yes, it might have created some confusion with the old .NET aka .NET Framework but I hope it's temporary. It's been five years of .NET-no-suffix and nine of it being cross-platform. At some point people should just educate themselves and stop thinking that .NET is somehow Windows only.
Good luck with that, the .NET team keeps referring this is a recurring problem trying to get new users that rather pick something else for their startups or teaching curriculum, just go listen to .NET podcasts where well known figures got interviewed.
> There is no .NET Core or .NET Framework since .NET 5.0 in 2020
There is both a .Net and a .Net Framework, with the latest .net framework update being about ~3 years old, years after .net 5 was released.
I'm finally working on migrating (migrate, not upgrade) from .Net framework 4.7.2 to .Net 9
It was a previously impossible / very difficult due to strong dependencies on functionality which only existed in .Net Framework.
With the continued development of Winforms on .Net 9+, it finally made sense to start migrating over.
There is both a .Net and a .Net Framework, with the latest .net framework update being about ~3 years old, years after .net 5 was released.
I'm finally working on migrating (migrate, not upgrade) from .Net framework 4.7.2 to .Net 9
It was a previously impossible / very difficult due to strong dependencies on functionality which only existed in .Net Framework.
With the continued development of Winforms on .Net 9+, it finally made sense to start migrating over.
.NET Core got renamed .NET in version 5. .NET Framework is still used as the name of the classic version of .NET that comes with Windows. See here:
https://learn.microsoft.com/en-us/dotnet/fundamentals/implem...
https://learn.microsoft.com/en-us/dotnet/fundamentals/implem...
I guess this is the kind of CVE that will make CISOs in BigCorps scream "fix it now!!" to everyone down the chain, right?
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.)
* 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?
Wow wonder how it was discovered. Looks like it’s been around for a while.
For context around the score https://github.com/dotnet/aspnetcore/issues/64033#issuecomme...
This appears to be the code change: https://github.com/dotnet/aspnetcore/commit/97a86434195a82fc...
Looks like a line ending problem. RejectsInvalidChunkExtensions seems to be the unit test that covers the actual concern.
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.
The bug itself doesn't enable any of those. An app using the library might have that vuln.
It's a generic problem with using CVSS to score library vulnerabilities. CVSS is designed around complete systems, so it's totally crap to apply it to libraries.
I see a lot of critical (9+) supposed JavaScript "remote code execution with no authentication" CVEs being posted...
Right, if you are running it in an NPM server exposed to malicious user input with no authentication. Actually it runs client side in the browser and at best it's a prototype pollution vuln with a much lower score.
I see a lot of critical (9+) supposed JavaScript "remote code execution with no authentication" CVEs being posted...
Right, if you are running it in an NPM server exposed to malicious user input with no authentication. Actually it runs client side in the browser and at best it's a prototype pollution vuln with a much lower score.
> This is a dumb way of scoring the bug.
The above is a motto for the entire vulnerability industrial complex.
The above is a motto for the entire vulnerability industrial complex.
Score which is based how someone could theoretically use the tool.
It might be right, but it also feels so wrong.
I would in reality probably rank this issue lower. And in some more properly engineered systems it would have lot less criticality.
It might be right, but it also feels so wrong.
I would in reality probably rank this issue lower. And in some more properly engineered systems it would have lot less criticality.
But:
> someone could theoretically use the tool
makes every single logic error a 9.9
> someone could theoretically use the tool
makes every single logic error a 9.9
> If you are running .NET 8 or later install the .NET update from Microsoft Update, then restart your application or reboot the machine.
This is why I advocate for .NET in serious business contexts. You often don't have to rebuild or redeploy your software if you are using the included batteries as intended. A devops intern could handle this fix. Contrast with virtually any other ecosystem.
This is why I advocate for .NET in serious business contexts. You often don't have to rebuild or redeploy your software if you are using the included batteries as intended. A devops intern could handle this fix. Contrast with virtually any other ecosystem.
> 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.
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.
>Instead, your software's lifecycle is entirely dependent on the OS' lifecycle. That seems worse.
It's not.
.NET updates are shipped with Windows Update, but can be installed separately.
Obviously for macOS and Linux you can't get them through Windows Update anyway.
It's not.
.NET updates are shipped with Windows Update, but can be installed separately.
Obviously for macOS and Linux you can't get them through Windows Update anyway.
Who doesn't use containers these days to deploy web apps?
Those outside your bubble.
Yes agreed, applying updates is very easy and pain free these days.
No different to using RHEL OpenJDK on Linux and running `dnf update`
I'm entirely confused. Am I right to assume that the actual exploit isn't published yet and still under embargo? Or am I missing some explanation of the actual issue here?
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.
"9.9 Critical"
It's not like these scores ever had a solid meaning, but throwing a 9.9 out there for this is nonsense.
It's just abusing an already weak system, making it that much weaker.
It's not like these scores ever had a solid meaning, but throwing a 9.9 out there for this is nonsense.
It's just abusing an already weak system, making it that much weaker.
at https://dotnet.microsoft.com/en-us/download/dotnet
They are 8.0.21 and 9.0.10
https://github.com/dotnet/core/blob/main/release-notes/8.0/8...
https://github.com/dotnet/core/blob/main/release-notes/9.0/9...
as per https://github.com/dotnet/aspnetcore/issues/64033