Looks like a line ending problem. RejectsInvalidChunkExtensions seems to be the unit test that covers the actual concern.
philipwhiuk 1 days ago [-]
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.
MattPalmer1086 23 hours ago [-]
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.
justin66 22 hours ago [-]
> This is a dumb way of scoring the bug.
The above is a motto for the entire vulnerability industrial complex.
Ekaros 24 hours ago [-]
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.
philipwhiuk 24 hours ago [-]
But:
> someone could theoretically use the tool
makes every single logic error a 9.9
yabones 1 days ago [-]
Note that this affects ".net core", not ".net framework"
It was released in February 2025, for those who think framework isn't supported.
ninjaoxygen 1 days ago [-]
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.
calebt3141 1 days ago [-]
> 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.
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...
ninjaoxygen 24 hours ago [-]
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.
And there is currently no official other supported version supported like .NET Framework 4.8 or simply .NET
ninjaoxygen 1 days ago [-]
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.
Hawxy 24 hours ago [-]
> 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.
pjmlp 23 hours ago [-]
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.
pverheggen 22 hours ago [-]
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.
orphea 16 hours ago [-]
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.
pjmlp 16 hours ago [-]
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.
SomeUserName432 23 hours ago [-]
> 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.
MarkSweep 23 hours ago [-]
.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:
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.
bob1029 1 days ago [-]
> 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.
wcoenen 24 hours ago [-]
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.
LikesPwsh 21 hours ago [-]
Yes
philipwhiuk 24 hours ago [-]
No different to using RHEL OpenJDK on Linux and running `dnf update`
BartjeD 1 days ago [-]
Yes agreed, applying updates is very easy and pain free these days.
pier25 23 hours ago [-]
Who doesn't use containers these days to deploy web apps?
qingcharles 21 hours ago [-]
I bare metal everything.
pier25 19 hours ago [-]
As do I but still use containers with dokku.
sebazzz 21 hours ago [-]
Those outside your bubble.
sofixa 22 hours ago [-]
> 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.
daveoc64 18 hours ago [-]
>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.
Zeekaas 1 days ago [-]
9.9 feels like the teacher who never gives out 10/10 or A
baq 23 hours ago [-]
would you rather have a nonsensical 10 for redis instead?
1 days ago [-]
darkwater 1 days ago [-]
I guess this is the kind of CVE that will make CISOs in BigCorps scream "fix it now!!" to everyone down the chain, right?
kstrauser 23 hours ago [-]
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.)
BartjeD 1 days ago [-]
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?
BartjeD 1 days ago [-]
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?
whizzter 20 hours ago [-]
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.
philipwhiuk 24 hours ago [-]
I mean it will now it's gone to the front of HN ;)
Wow wonder how it was discovered. Looks like it’s been around for a while.
yread 23 hours ago [-]
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
whizzter 20 hours ago [-]
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
GordonS 22 hours ago [-]
I don't remember exactly when, but I'm sure I recall Kestrel being declared production ready a few years back.
qingcharles 21 hours ago [-]
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)
fabian2k 23 hours ago [-]
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?
SideburnsOfDoom 23 hours ago [-]
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.
SideburnsOfDoom 23 hours ago [-]
FYI, the fixed versions were released yesterday, the 14th, in the October 2025 "Patch Tuesday"
The bug itself doesn't enable any of those. An app using the library might have that vuln.
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.
The above is a motto for the entire vulnerability industrial complex.
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.
> someone could theoretically use the tool
makes every single logic error a 9.9
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
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.
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.
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...
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.
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.
And there is currently no official other supported version supported like .NET Framework 4.8 or simply .NET
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.
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.
Additionally the mistake to rename .NET Core as .NET is the main reason many people still think .NET is Windows only.
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.
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.
https://learn.microsoft.com/en-us/dotnet/fundamentals/implem...
That started in .NET 5.0 in November 2020, which was nearly 5 years ago now.
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.
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.
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.
* 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.)
It sort of implies it will be quikcly under active investigation by hostile actors, and then get's raised to an urgent threat?
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.
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
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
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.