41–50 of 57 posts
Note that this affects ".net core", not ".net framework" 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.
Is this another instance of HTTP desync?
> 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.
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.
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
For context around the score https://github.com/dotnet/aspnetcore/issues/64033#issuecomme...
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 above is a motto for the entire vulnerability industrial complex.
> 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 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.
> 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.
Who doesn't use containers these days to deploy web apps?
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
I don't remember exactly when, but I'm sure I recall Kestrel being declared production ready a few years back.
> 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.
Who doesn't use containers these days to deploy web apps?