Understanding the Worst .NET Vulnerability
14 comments
·October 28, 2025pastage
radicalbyte
The problem is that we have a culture of accepting mangled requests on the web. This happens in application code too - because web developers are sloppy it's common to either disable or not use strict input validation.
In a pure .Net world it's the norm to use strict input validation and tell clients to fix their bad requests and this looks like one of those cultural blindspots. "We" wouldn't naturally consider a case where a server accepted a request which has not been strictly validated. With the move to .Net Core and a broadening of the scope to not only target enterprises and we'll find issues like this....
r0x0r007
That feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"
Traubenfuchs
It's pretty much the same in Javaland with maven and spring.
Create a new project with the latest spring version, and maven will warn you.
At this point I consider this worthless noise.
cm2187
And now that everything is a package, it won’t get fixed with windows update. Which means that if the website isn’t actively developed and regularly deployed, it will remain vulnerable
lsbehe
M$ offers system wide installations. Those don't seem to be updated automatically either but at least I don't have to deploy 6 servers now.
Uvix
On Linux, system-wide installations are handled through the system's package manager.
On Windows, if you have the "Install updates for other Microsoft products" option enabled, .NET [Core] runtimes will be updated through Windows Update.
If the domain's group policy won't let you turn it on from the UI (or if you want to turn it on programmatically for other reasons), the PowerShell 7 installer has a PowerShell script that can be adapted to do the trick: https://github.com/PowerShell/PowerShell/blob/ba02868d0fa1d7...
CharlieDigital
That's a Good Thing rather than shipping vulnerable code.
fabian2k
> And as a final reminder, even though request smuggling is typically described and demonstrated using a proxy in front of your server, just not using a proxy does not mean you're automatically safe. If you're reading, manipulating, or forwarding request streams directly in ASP.NET Core, as opposed to just relying on the built-in model binding, then you might be at risk to request smuggling attacks.
I'm probably missing something, but I still don't get how this would work without a proxy unless my own code manually parses the request from scratch. Or maybe that is what the author means.
The vulnerability, as far as I understand it, relies on two components interpreting these chunks differently. So one of them has to read \r or \n as valid markers for the chunk end, and the other one must only allow \r\n as specified.
Kestrel used to allow \r and \n (and the fix is to not do that anymore). So only if my own code parses these chunks and uses \r\n would I be vulnerable, or?
The proxy version of the vulnerability seems quite clear to me, and pretty dangerous as .NET parses non-compliant and would thereby be vulnerable behind any compliant proxy (if the proxy is relevant for security aspects).
But the single application version of the vulnerability seems to me to be very unlikely and to require essentially having a separate full HTTP parser in my own application code. Am I missing something here?
forksspoons
It sounds like this is anything built upon Kestrel which is a lot. I was going to try to list it all here, but holy cow.
null
rana762
[dead]
It has been in the making for at least ten years, the problem for me has been that that production environments and test environments are not the same when you use proxys. So you need to check both, and you need to have the same type of connection that your customers use.
https://www.youtube.com/watch?v=B2qePLeI-s8
From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090