S08E07 36mSeason 8
S08E07
0:0036m
Episode Summary
In this bonus episode of The Modern .NET Show, we welcomed Hayden Barnes back to the recording booth to talk about what has been called “the worst .NET vulnerability ever”, what it is, how it affects you (because it will), and what you need to do to protect your applications, and your data.
Episode Transcription
Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.
This episode is a super important, top-of-the-heap, bonus episode that you definitely need to be listening to.
I, basically, reached out to Hayden Barnes, who we’ve just now had on the show to talk about .NET never-ending support and what happens when you drop out of support with Microsoft. The reason that I did that, and the reason that this intro is so raw is because we talked about what is known as “the worst CVE for the internet as a whole. If you want to Google it while we’re talking right now, look for “CVE 2025-55315”. We’ll get into it in a moment, but pretty much everything on the internet is susceptible to this, and only .NET 8, 9, and 10 have a fix. Nothing else has a fix in the. NET space.
You will find out in this episode what it is, what problems it can cause you, and how to solve those problems. Please stick around and listen, folks.
Thank you, Matt, the editor, for putting this together so quickly. Anyway, on with the episode.
I’m not even going to do the dotnet new podcast thing. It’s that important.
Jamie
So Hayden, welcome back to the show. We just released an episode with you talking about . NET, never-ending support, HeroDevs, and why folks need to keep their like runtimes and SDKs up to date; and then, "the CVE" happened.
Hayden
"The CVE."
Jamie
Yeah, right. "The CVE". So, you know, first off, welcome back.
Hayden
Thank you. Thank you. Thanks for having me back.
Jamie
And yeah, for those who haven’t heard about it. The CVE, the reason why we’re referring to it like that, is because it has been publicised as "the very worst CVE for all .NET apps ever." But it is quite a worrisome thing.
What we’re gonna do is we’re gonna go into the CVE real quick, tell you all what you need to know about what it is, maybe how to how and why it’s such a big problem, the mitigation steps for if you’re on a supported .NET, and the potential mitigation steps for if you’re not on a supported.
What we’re gonna do is we’re gonna go into the CVE real quick, tell you all what you need to know about what it is, maybe how to how and why it’s such a big problem, the mitigation steps for if you’re on a supported .NET, and the potential mitigation steps for if you’re not on a supported.
Hayden
Yeah. Yeah, this is a fun one.
Jamie
Okay. So I guess first thing that we should really sort of bat around is like, what is this CVE? Like we can rattle off the number, if folks really want, but I’ll put that in the show notes because it’s like 2025 blah-de-blah-de-blah, right? All heck has broken loose, right? You don’t need to know the number, you just need to know that, you know, you’re likely affected.
Hayden
Yes. And another thing to know is that this CVE is rated with a CVSS score of 9.9. That is 9.9 out of ten. This is basically the next the most severe CVE rating a CVE could achieve, which means We need to take notice.
Jamie
Yes.
Hayden
It is rated that way, and it was rated by Microsoft, who reported the CVE, because of the range of attacks it enables. And we’re gonna have to do a little bit of deep dive into HTTP to understand.
This CVE affects ASP .NET. It affects web host. And this goes back to a blog that was published in June called "Funky Chunks." There is a standard in HTTP/1 that allows for what we call chunk extensions. Chunking in this context Allows requests to a server to flow in a binary format, in smaller pieces. Basically, it allows you to divide up binary data in these headers and submit them one piece at a time. There’s a number of reasons why you might want to do this, you know, minimal buffers, you know, other implementation details.
Another thing to know is that these chunks have within them a section for metadata. Now, why would HTTP requests that contain serialised binary data have a section for metadata. There’s no reason for it to.
This CVE affects ASP .NET. It affects web host. And this goes back to a blog that was published in June called "Funky Chunks." There is a standard in HTTP/1 that allows for what we call chunk extensions. Chunking in this context Allows requests to a server to flow in a binary format, in smaller pieces. Basically, it allows you to divide up binary data in these headers and submit them one piece at a time. There’s a number of reasons why you might want to do this, you know, minimal buffers, you know, other implementation details.
Another thing to know is that these chunks have within them a section for metadata. Now, why would HTTP requests that contain serialised binary data have a section for metadata. There’s no reason for it to.
Jamie
Uh-huh.
Hayden
It was part of the specification. It was a thought. you know, that there may be a a use for this eventually, that just never materialised. And that is where The issue with the CVE lies is the parsing of the metadata in these chunked requests, specifically in HTTP/1. This doesn’t affect HTTP/2 or 3. Specifically this legacy protocol.
Jamie
So from what you’ve said, my understanding is: HTTP/1, there’s this mad implementation that is baked into HTTP/1 where, essentially, I can chunk up my request into… perhaps arbitrary sizes, then add metadata into those chunks. So it could be: chunk one, can be, yu know, if I’m sending you "hello world," I might want to break that "hello world" into chunks of two characters, which means I’d get what? I wanna say seven, eight chunks? But then within each of those chunks, I can store metadata about the chunk. So I can say like "starts at", "ends at", "length of", that kind of thing, right?
Hayden
Exactly. Exactly.
And there’s a number of reasons why you might want chunking, you know, network efficiency, dealing with devices with small buffers. That in and of itself is not the problem.
The problem is how new line characters are interpreted within the metadata. Specifically our good old friends CR and LF: carriage return and line feed. And it turns out that by manipulating carriage return and lf—
And the one way to think about this is a proxy. Let’s say you have a proxy in front of your web service. This proxy receives a single malformed chunked HTTP request with these invalid new character lines. And it breaks them up and sends them as two separate HTTP requests past that proxy to your server. That server then interprets those requests individually. Whereas you may have security software or a policy that prohibits inbound queries to
And there’s a number of reasons why you might want chunking, you know, network efficiency, dealing with devices with small buffers. That in and of itself is not the problem.
The problem is how new line characters are interpreted within the metadata. Specifically our good old friends CR and LF: carriage return and line feed. And it turns out that by manipulating carriage return and lf—
/r and /n in the actual request. You can craft a malicious HTTP request that could bypass certain security restrictions and and open you up to a wide range of potential attacks.And the one way to think about this is a proxy. Let’s say you have a proxy in front of your web service. This proxy receives a single malformed chunked HTTP request with these invalid new character lines. And it breaks them up and sends them as two separate HTTP requests past that proxy to your server. That server then interprets those requests individually. Whereas you may have security software or a policy that prohibits inbound queries to
/admin, but you craft a malformed request that slips past the proxy and hits your web server and allows you to pull /admin past the proxy.Jamie
Oh okay I see. Oh.
Hayden
Yes.
Jamie
Wow, okay.
Hayden
Another way to think about this is actually at the ASP .NET application layer.
You’re not necessarily leveraging a proxy, but the Kestrel service within ASP .NET is receiving this request. And your ASP .NET application is parsing this request, you know, looking at the body, looking at the header. So in a sense, Kestrel is functioning as the proxy in the previous example. It’s accepting it, and parsing it.
In this CVE, the interpretation of the new character line enabled these smuggled chunks to be processed with the invalid new line characters in the metadata. So you could conceivably pull
So because this metadata in this protocol, in these chunk requests, isn’t widely used different proxies and network services handle them differently. Some tooling, like the Go standard library, simply ignores them. Whereas other network applications and services parse these newline characters, including CR and LF, differently. And depending on how these network services parse those, it can enable these malformed requests to be interpreted as separate requests past, you know, their initial you know acceptance by Kestrel, allowing a whole host of vulnerabilities to be exploited.
And ASP .NET is not alone in this. There are several other popular web frameworks, web engines that are affected by this phenomenon and receive patches. Not all of them received a 9.9. That was, again, assigned by Microsoft because they saw the potential, depending on how your ASP .NET application was written, for what could happen if your ASP .NET application did not have the appropriate protocols for handling these requests.
So that’s where we get the 9.9, but it is not unique to ASP .NET and there is no consensus on handling this metadata because this is just a feature in the protocol that was never used.
You’re not necessarily leveraging a proxy, but the Kestrel service within ASP .NET is receiving this request. And your ASP .NET application is parsing this request, you know, looking at the body, looking at the header. So in a sense, Kestrel is functioning as the proxy in the previous example. It’s accepting it, and parsing it.
In this CVE, the interpretation of the new character line enabled these smuggled chunks to be processed with the invalid new line characters in the metadata. So you could conceivably pull
/admin; you could engage in you know cross-site attacks. And that’s the reason why Microsoft rated this a 9.9, because a lot of web services don’t actually know what to do with this metadata in these chunked requests. A lot of them, like for example, the Go standard library, simply ignores them.So because this metadata in this protocol, in these chunk requests, isn’t widely used different proxies and network services handle them differently. Some tooling, like the Go standard library, simply ignores them. Whereas other network applications and services parse these newline characters, including CR and LF, differently. And depending on how these network services parse those, it can enable these malformed requests to be interpreted as separate requests past, you know, their initial you know acceptance by Kestrel, allowing a whole host of vulnerabilities to be exploited.
And ASP .NET is not alone in this. There are several other popular web frameworks, web engines that are affected by this phenomenon and receive patches. Not all of them received a 9.9. That was, again, assigned by Microsoft because they saw the potential, depending on how your ASP .NET application was written, for what could happen if your ASP .NET application did not have the appropriate protocols for handling these requests.
So that’s where we get the 9.9, but it is not unique to ASP .NET and there is no consensus on handling this metadata because this is just a feature in the protocol that was never used.
Jamie
Right. First though I have is A) if it depends on how I’ve set up my app, do I need to worry? And B), I guess from what you’re hinting at there, it isn’t just a .NET problem, right? This is a "lots of different ecosystems" problem.
Hayden
Yes, very much so. It has been addressed in other ecosystems. It’s come up in other ecosystems.
It’s very hard to tell a developer if their application could be affected by this without close examination of the code. Are they actually parsing HTTP requests? You know, looking at the headers, looking at the body of the request, and applying logic to route those. If you are, you’re at higher risk. But the best way to secure against this is to upgrade to the latest versions of .NET 8, 9, and now 10 that all contain fixes for this parser error in Kestrel in ASP. NET.
It’s very hard to tell a developer if their application could be affected by this without close examination of the code. Are they actually parsing HTTP requests? You know, looking at the headers, looking at the body of the request, and applying logic to route those. If you are, you’re at higher risk. But the best way to secure against this is to upgrade to the latest versions of .NET 8, 9, and now 10 that all contain fixes for this parser error in Kestrel in ASP. NET.
Jamie
Okay. So I guess mitigation path one: if you’re already on version 8, 9, or 10: we’ll cover that in a moment.
But if you’re not: you need to upgrade, right? That’s The beginning and end of it, right? It’s just upgrade.
But if you’re not: you need to upgrade, right? That’s The beginning and end of it, right? It’s just upgrade.
Hayden
Yeah.
Jamie
I know that’s a super tall ask, but.
Hayden
it can be, but the the default advice here is to upgrade and get the patch. You know, run on the latest supported versions of. NET that receive these security patches from Microsoft and the rest of the. NET community.
Jamie
Okay, so let’s say I’m on .NET 5 and I’ve been putting off upgrading for a while, right? I may or may not be using a real example, I can’t say. But let’s say I’m on .NET 5 and I’ve been putting off upgrading for a while. This should be the kick up the butt that I need to go get buy-in from whomever the decision maker is to upgrade, right?
Hayden
It should be. It should be.
Ideally, you are in an organisation that has the resources, the time, budget to plan and execute those migrations on time, you know, to always remain within the .NET LTS, long-term support window; which are the even number builds. But as we know, not everyone does.
Ideally, you are in an organisation that has the resources, the time, budget to plan and execute those migrations on time, you know, to always remain within the .NET LTS, long-term support window; which are the even number builds. But as we know, not everyone does.
Jamie
Yeah, that’s true.
Hayden
And we know that this particular vulnerability affects .NET Core all the way back to 3.0. So shout out to Andrew Lock who wrote a great analysis of this CVE, and tested it, and confirmed it back to .NET 3.0.
Jamie
Wow!
That’s yeah, that’s kind of scary.
And just to just to reiterate, folks, this is, someone could just one day send a request to your webapp that is using these Funky Chunks and just, like embed a second request inside of the first one and, guess what, it gets through, right?
My understanding is perhaps there isn’t an easily accessible way to stop this at the firewall stage, but we want to do this defence in depth, right? We don’t just want to focus on the firewall or entry point, because if the firewall gets compromised, it still gets through. Right?
That’s yeah, that’s kind of scary.
And just to just to reiterate, folks, this is, someone could just one day send a request to your webapp that is using these Funky Chunks and just, like embed a second request inside of the first one and, guess what, it gets through, right?
My understanding is perhaps there isn’t an easily accessible way to stop this at the firewall stage, but we want to do this defence in depth, right? We don’t just want to focus on the firewall or entry point, because if the firewall gets compromised, it still gets through. Right?
Hayden
Right.
Jamie
So defence in depth.
Hayden
Yeah. I mean there there are mitigation steps. that you can apply, things like a firewall, things like putting a proxy that handles these correctly in front of your legacy. NET Core application. And, for example, some Azure uh like Azure App Services, uh their built-in proxy filters these out. So even legacy. NET applications would not be vulnerable.
But if we’re doing defence in depth, migrating to a in-support version or, secondarily, adopting a secured version of .NET that is supported in post EOL support is the appropriate way to move forward.
But if we’re doing defence in depth, migrating to a in-support version or, secondarily, adopting a secured version of .NET that is supported in post EOL support is the appropriate way to move forward.
Jamie
Yes. Because that’s the most important thing. We’ll come back to that in a moment, but like the most important thing is: What if I am on .NET 5 and I don’t have the requirement to move on? That has been end of life’d, right?
And so my understanding is Microsoft are likely to not ever produce an update to fix this in the earlier versions because of a bunch of reasons; but essentially there’s not a great deal of time, there’s not a great deal of budget, and the world has moved on a little bit since then.
And so my understanding is Microsoft are likely to not ever produce an update to fix this in the earlier versions because of a bunch of reasons; but essentially there’s not a great deal of time, there’s not a great deal of budget, and the world has moved on a little bit since then.
Hayden
Right. End of life is end of life. And Microsoft will not release security updates past the security window for .NET. And that’s not, you know, that’s I’m not criticizing Microsoft for that. I think that is a valid case. You know, they’ve laid out their support plan. Enterprise companies are aware of it, you know, and can plan their migrations accordingly, ideally. But yeah, you you are not getting a fix for this on 5 or 6 or 7.
Jamie
And I think that’s only fair, right? Because just real quick to talk about that, if Microsoft or rather if the .NET team were suddenly to stop development on. NET 10— because this was announced, like you said, a few months ago, right? So if they had stopped development of. NET 10 to fix this for all of the other .NETs, and then carried on with. NET 10, it would have delayed. NET 10, right?
Hayden
Right.
Jamie
That’s no good for everybody.
Hayden
Yeah, and. NET 10 is awesome. like the number of new features and performance enhancements, you know, I want Microsoft to continue developing upstream .NET. It just keeps getting better. So yeah, it’s a defensible resource allocation case that Microsoft not, you know, allocate resources to end-of-life versions.
You know, another thing to note is if you are utilising tooling such as CVE scanning, maybe in your CI/CD pipeline or your endpoint management tools. The versions listed in this CVE only include the affected versions of .NET 8, 9, and 10.
You know, another thing to note is if you are utilising tooling such as CVE scanning, maybe in your CI/CD pipeline or your endpoint management tools. The versions listed in this CVE only include the affected versions of .NET 8, 9, and 10.
Jamie
Ah.
Hayden
So those CVE scanning tools in your CI/CD system or your endpoint management tooling are not going to detect that this CVE is present if you have vulnerable versions of .NET 6 or 7 running and installed. You know, it could give you a false sense of security after running that report, say, "oh, there’s no CVEs here." Your scanner is not going to report the CVE in .NET 6 because the CVE doesn’t have 6 listed in the affected versions.
So it’s very important to understand what versions of .NET are running in your stack, across your organisation. And of the customers and developers I talk to, in a lot of cases, it’s basically all of them. All the versions at some stage. So, you know, when evaluating your security posture, you have to have a plan for migration and then handling security vulnerabilities in post-EOL versions of your stack that may not be detected by your standard security tooling. You have to be proactive here.
So it’s very important to understand what versions of .NET are running in your stack, across your organisation. And of the customers and developers I talk to, in a lot of cases, it’s basically all of them. All the versions at some stage. So, you know, when evaluating your security posture, you have to have a plan for migration and then handling security vulnerabilities in post-EOL versions of your stack that may not be detected by your standard security tooling. You have to be proactive here.
Jamie
Yeah. That right there is the scary bit, right?
Just to sort of underline that: if you’re running a version of. NET that is pre-.NET eight, and you run the scanning tool, it’s not going to say that you are vulnerable to it. But we know through Hayden’s work and through Andrew Lock’s work that .NET Core 3.0 and above are vulnerable to it, right? So you are likely running something that is vulnerable.
If you are listening to this episode then you are either super interested in .NET and not done anything with it, or you are running something in production which is vulnerable to the CVE.
Just to sort of underline that: if you’re running a version of. NET that is pre-.NET eight, and you run the scanning tool, it’s not going to say that you are vulnerable to it. But we know through Hayden’s work and through Andrew Lock’s work that .NET Core 3.0 and above are vulnerable to it, right? So you are likely running something that is vulnerable.
If you are listening to this episode then you are either super interested in .NET and not done anything with it, or you are running something in production which is vulnerable to the CVE.
Hayden
Right. And that’s exactly why I adapted the functional test that was included as part of the patch for this in 8, 9, and 10 to a standalone console application that could be run on. NET 6 and above. I think Andrew tweaked it so it could run on some slightly older versions. That would verify, "is what I’m running this on affected?" so that we could highlight that for users, and developers, and system administrators out there.
Jamie
Oh okay. So so let’s say I’m on 8, 9, 10… although 10’s just come out, I would assume that 10 would probably have a fix for it, but it doesn’t matter. I’m on 8, 8, 10 and I’m worried about this. I just need to download the update, just go to get.dot.net and download the SDK in the runtime and we’re happy?
Hayden
Pretty much. Pretty much.
Jamie
Okay.
Hayden
The CVE did affect .NET 10 RC1, but was fixed in .NET 10 RC2. So if you have the GA of 10, you are you are protected. But yes, updating your runtime, including your ASP .NET runtime; updating your SDK; and specifically the Kestrel library that is leveraged by ASP .NET. Yeah, and you’re protected.
Jamie
So here comes the elephant in the room then: I’m on. NET 6. What do I do?
Hayden
Right.
In the short-term, you know, you have some mitigation strategies. You know, you have things like proxies and you can monitor for these types of requests so, at least you’ll know if you’re potentially under attack. But long-term you need to migrate to a supported version of .NET. And in the interim, my recommendation is that you obtain post-EOL support for .NET 6 while you plan and execute that migration to a in-support version of .NET, whether that’s 8 or ten.
In the short-term, you know, you have some mitigation strategies. You know, you have things like proxies and you can monitor for these types of requests so, at least you’ll know if you’re potentially under attack. But long-term you need to migrate to a supported version of .NET. And in the interim, my recommendation is that you obtain post-EOL support for .NET 6 while you plan and execute that migration to a in-support version of .NET, whether that’s 8 or ten.
Jamie
Long-term: figure out how to upgrade your apps. Short-term: figure out your own mitigation strategies and perhaps include Hero Devs in that mitigation strategy then?
Hayden
Exactly.
If you have infrastructure that is accessible on the web, and cannot be air gapped, that is running .NET 6, you know, I wouldn’t consider the interim mitigations sufficient. You you need to migrate. And if you cannot migrate, you need post-EOL support of a build of .NET 6 that has this patch applied, like NES for .NET from Hero Devs.
If you have, you know, some applications there, you know, you can air gap and sufficiently secure, maybe you can delay But, you know, that’s a risk. Again, this might not be detected by security scanners. And if you’re working for a business that is in a regulated industry, you know, finance or health, you really have an increased duty of care to not really be running any unpatched .NET that is vulnerable to this, even if you can air gap it.
If you have infrastructure that is accessible on the web, and cannot be air gapped, that is running .NET 6, you know, I wouldn’t consider the interim mitigations sufficient. You you need to migrate. And if you cannot migrate, you need post-EOL support of a build of .NET 6 that has this patch applied, like NES for .NET from Hero Devs.
If you have, you know, some applications there, you know, you can air gap and sufficiently secure, maybe you can delay But, you know, that’s a risk. Again, this might not be detected by security scanners. And if you’re working for a business that is in a regulated industry, you know, finance or health, you really have an increased duty of care to not really be running any unpatched .NET that is vulnerable to this, even if you can air gap it.
Jamie
Okay, let’s say I have the ability to air gap. I should air gap anyway, because if I have that ability, I should be doing that anyway, but let’s say we aren’t. We air gap.
We then look at how do we mitigate this ourselves. We can’t really do it, so maybe we look at the pros and cons of upgrading versus contacting Hero Devs or some other post EOL .NET support system. I’m not sure there are any, but just in case, right, I wanna do the old BBC thing with which is, you know, "there are other sources of this kind of thing available."
But let’s say there aren’t, so we get in touch with Hero Devs. And then we can, I guess "we," Jamie, the developer, can then rely on Hero Devs to support me for log enough so that then I can upgrade, if I need to.
Well I do need to, but otherwise, you know I’m out of support, right? I need to be in support. Like you said, if I’m working in some kind of regulated industry, dealing with people’s information, dealing with people with some kind of finance. Well, just to be a good steward of the world, right, you should upgrade.
We then look at how do we mitigate this ourselves. We can’t really do it, so maybe we look at the pros and cons of upgrading versus contacting Hero Devs or some other post EOL .NET support system. I’m not sure there are any, but just in case, right, I wanna do the old BBC thing with which is, you know, "there are other sources of this kind of thing available."
But let’s say there aren’t, so we get in touch with Hero Devs. And then we can, I guess "we," Jamie, the developer, can then rely on Hero Devs to support me for log enough so that then I can upgrade, if I need to.
Well I do need to, but otherwise, you know I’m out of support, right? I need to be in support. Like you said, if I’m working in some kind of regulated industry, dealing with people’s information, dealing with people with some kind of finance. Well, just to be a good steward of the world, right, you should upgrade.
Hayden
Yes, yes. Even if you’re not as altruistic as that, the risk of fines and litigation from potentially leaking that personally identifiable information, when it’s ultimately determined that it because you didn’t, you know, make the migration in time, you know. So altruism, yes. But there’s also a stick there too.
Jamie
Yes, yes.
And I guess that could then be used, I’m not saying anybody do this, but you can use that as leverage against the decision maker. You know, along the lines of, "not if, but when," because obviously the double-edged sword of making a lot of noise about this CVE and others like it and how people need to upgrade, is that those malicious actors that don’t know about this CVE already are now hearing about it, too.
And so there will likely be an uptick in attempts at sending these kinds of requests to things that are known to be running. NET to see if they are vulnerable. Perhaps the first couple of attacks might be, "is this vulnerable?" that kind of attack, right? Rather than, "give me all the data," just like, "is this vulnerable?" And then folks may circle back and then do a, "give me all of the data."
And the scariest thing, folks is that this can work if you’re authenticated, right? So if you’re doing something… yeah, if your if your user is authenticated, they can smuggle a second request inside of the first one that does things like Hayden was saying about exfiltrating data or getting something that, maybe they have the ability to get to, but maybe you can’t see it going in, but you’ll see it coming back out again. Right. Or you might not be able to log it and things like that, right.
So there could be requests that you’re already receiving… I hate to be the guy who does that, but there could be requests that you’re already seeing, already receiving that you’re not seeing, Right? That’s the scary thing. I hate to be the guy who goes, "oh, but wouldn’t it be terrible if it happened to you?" But guess what? It’s probably already happening to you, right?
And I guess that could then be used, I’m not saying anybody do this, but you can use that as leverage against the decision maker. You know, along the lines of, "not if, but when," because obviously the double-edged sword of making a lot of noise about this CVE and others like it and how people need to upgrade, is that those malicious actors that don’t know about this CVE already are now hearing about it, too.
And so there will likely be an uptick in attempts at sending these kinds of requests to things that are known to be running. NET to see if they are vulnerable. Perhaps the first couple of attacks might be, "is this vulnerable?" that kind of attack, right? Rather than, "give me all the data," just like, "is this vulnerable?" And then folks may circle back and then do a, "give me all of the data."
And the scariest thing, folks is that this can work if you’re authenticated, right? So if you’re doing something… yeah, if your if your user is authenticated, they can smuggle a second request inside of the first one that does things like Hayden was saying about exfiltrating data or getting something that, maybe they have the ability to get to, but maybe you can’t see it going in, but you’ll see it coming back out again. Right. Or you might not be able to log it and things like that, right.
So there could be requests that you’re already receiving… I hate to be the guy who does that, but there could be requests that you’re already seeing, already receiving that you’re not seeing, Right? That’s the scary thing. I hate to be the guy who goes, "oh, but wouldn’t it be terrible if it happened to you?" But guess what? It’s probably already happening to you, right?
Hayden
Yeah.
Jamie
You know, you need to be doing something.
Hayden
Yeah, and you know, HTTP smuggling is not a new concept. It has been discussed since the early 2000s. This particular exploit using malformed chunking has been highlighted recently, and as I mentioned affects other ecosystems. So this is a known vector for attack on web-based applications and network services. So it’s very likely this is actively happening.
You know, we we know about the 9.9 CVE on .NET because Microsoft assigned that 9.9 with considering all the potential ramifications of what would happen. But we know of CVEs across other ecosystems, including Java, that that suffer the same basic vulnerability of misinterpreting these new line characters in this metadata and allowing this type of smuggling to occur.
So it’s out there. It’s live and it’s affecting not just. NET but other ecosystems.
You know, we we know about the 9.9 CVE on .NET because Microsoft assigned that 9.9 with considering all the potential ramifications of what would happen. But we know of CVEs across other ecosystems, including Java, that that suffer the same basic vulnerability of misinterpreting these new line characters in this metadata and allowing this type of smuggling to occur.
So it’s out there. It’s live and it’s affecting not just. NET but other ecosystems.
Jamie
Right, right.
So I guess because we’re all good stewards of the internet and good stewards of being engineers, I guess the hidden request there, or not so hidden request there, is "go tell your friends. Not necessarily that they have to listen to this conversation, but that they need to look into."
And I’ve just searched it now. "CVE2025-55315" or just Google "Andrew Lock CVE" or Google "Hero Dev CVE", right? There’s probably some search engine optimisation happening there, you can get straight to it. But I’ll link to everything in the show notes.
So I guess because we’re all good stewards of the internet and good stewards of being engineers, I guess the hidden request there, or not so hidden request there, is "go tell your friends. Not necessarily that they have to listen to this conversation, but that they need to look into."
And I’ve just searched it now. "CVE2025-55315" or just Google "Andrew Lock CVE" or Google "Hero Dev CVE", right? There’s probably some search engine optimisation happening there, you can get straight to it. But I’ll link to everything in the show notes.
Hayden
Right. And we’ll also link to Funky Chunks, which is the article that introduces this concept that is resulted in this CVE.
Jamie
Yes, absolutely.
So just to revisit some of the the steps that devs need to know about:
So if we’re on . NET 8, 9, or 10. If you’re on 10 and you’re running the 10.0, the general availability, the version that was released not a few weeks ago at .NET Conf, right? That version, not the release candidates. If you’re on that version, you’re likely already safe.
If you’re on release candidate 1 or 2, you may have to go and upgrade. But if you’re on a release candidate of .NET 10, it should just be: re-download the SDK, re-download the runtime, build and publish, and you’re good. As long as you install the runtime wherever you’re running it.
If you’re on 8 or 9, similar steps: download the SDK, download the runtime, build, deploy, good.
If you’re in a container, depending on how you’re doing the container, if you’re in 8, 9, or 10: just re-pull the container and redeploy. You’ll probably find find that the container has been updated for you.
If you’re pre-6: this is your kick up the butt moment, or rather this is the decision maker’s kick-up the butt moment, to get upgraded. Because you are not supported if you are pre-6.
If you are on 6: then you need to put some mitigation steps in process. Put some mitigation processes in place. That’s the phrase I was looking for. And to potentially reach out to Hayden and his colleagues over at Hero Devs to be able to get that extra support whilst you figure out, "what does upgrading look like?" Because it’s, you know, other than the work that Hayden and the wonderful people over at Hero Devs have done, there is no support for fixing this in .NET 6.
So pre-6: get upgraded.
If you’re on six: contact Hayden or contact Hero Devs and start that upgrade process whilst you are being protected.
If you’re on 8, 9 or 10: update your stuff, right?
Did I get that right? I hope I got that right.
So just to revisit some of the the steps that devs need to know about:
So if we’re on . NET 8, 9, or 10. If you’re on 10 and you’re running the 10.0, the general availability, the version that was released not a few weeks ago at .NET Conf, right? That version, not the release candidates. If you’re on that version, you’re likely already safe.
If you’re on release candidate 1 or 2, you may have to go and upgrade. But if you’re on a release candidate of .NET 10, it should just be: re-download the SDK, re-download the runtime, build and publish, and you’re good. As long as you install the runtime wherever you’re running it.
If you’re on 8 or 9, similar steps: download the SDK, download the runtime, build, deploy, good.
If you’re in a container, depending on how you’re doing the container, if you’re in 8, 9, or 10: just re-pull the container and redeploy. You’ll probably find find that the container has been updated for you.
If you’re pre-6: this is your kick up the butt moment, or rather this is the decision maker’s kick-up the butt moment, to get upgraded. Because you are not supported if you are pre-6.
If you are on 6: then you need to put some mitigation steps in process. Put some mitigation processes in place. That’s the phrase I was looking for. And to potentially reach out to Hayden and his colleagues over at Hero Devs to be able to get that extra support whilst you figure out, "what does upgrading look like?" Because it’s, you know, other than the work that Hayden and the wonderful people over at Hero Devs have done, there is no support for fixing this in .NET 6.
So pre-6: get upgraded.
If you’re on six: contact Hayden or contact Hero Devs and start that upgrade process whilst you are being protected.
If you’re on 8, 9 or 10: update your stuff, right?
Did I get that right? I hope I got that right.
Hayden
Yeah, that’s exactly right.
Jamie
Oh my goodness. This is some scary stuff, right? Some real scary stuff. Oof.
And we’ve said it a few times, Hayden, but how do I get in touch with Hero Devs? Is it just Google Bing "Hero Devs" or like I’ll put a link in the show notes, folks?
And we’ve said it a few times, Hayden, but how do I get in touch with Hero Devs? Is it just Google Bing "Hero Devs" or like I’ll put a link in the show notes, folks?
Hayden
Yeah,
herodevs.com.
Jamie
Okay, cool. And then if folks have any questions, can they reach out to you via like Blue Sky, Mastadon, all those socials and things?
Hayden
I’m on all of those.
Jamie
Amazing.
If you have missed that, or I haven’t put it in the show notes when you’re listening, go back to the previous episode. The links will be in the show notes.
Oh my goodness. Hayden, thank you so much for coming back and talking through this. I’m sure that there is lots and lots more things to talk about with this one particular CVE, because this is a properly dangerous thing. Like you said, right, they’ve rated it 9.9 because of the potential, because there isn’t actually a… like there isn’t… how do I put it?
If I leave my front door unlocked and wide open, and somebody walks past, those are the prerequisites for someone to walk into my house, right? However, this is kind of like having a door that is locked and closed, but has a gigantic hole in it that you can just climb through.
If you have missed that, or I haven’t put it in the show notes when you’re listening, go back to the previous episode. The links will be in the show notes.
Oh my goodness. Hayden, thank you so much for coming back and talking through this. I’m sure that there is lots and lots more things to talk about with this one particular CVE, because this is a properly dangerous thing. Like you said, right, they’ve rated it 9.9 because of the potential, because there isn’t actually a… like there isn’t… how do I put it?
If I leave my front door unlocked and wide open, and somebody walks past, those are the prerequisites for someone to walk into my house, right? However, this is kind of like having a door that is locked and closed, but has a gigantic hole in it that you can just climb through.
Hayden
Right.
Jamie
Maybe. I don’t know. Maybe it’s not the world’s greatest metaphor, or maybe that it’s a key that unlocks my front door and my back door at the same time. I don’t know. I’m trying to come up with a metaphor that folks can use. And I don’t think there is one.
Hayden
Yeah, it would be by unlocking your front door, you also got access to the safe.
Jamie
Ah, that’s much better. Thank you. Yes. That’s scary.
Hayden
You were able to sneak the pin code to the safe through unlocking the front door. So the front door is open, and now you go straight to the safe and you have all the goodies.
Jamie
Yes, that’s it, that’s it. Because nine times out of ten, people won’t know that they can unlock the safe whilst unlocking the door. And so they’ll leave it. But the one malicious actor who knows that they can get to your entire kingdom, and exfiltrate all your data.
My worry is that in the AppSec… I know we’ve we’ve started the wrap up, but I just want to say this right: My worry is that in the AppSec space, there’s a lot of fear because, rightfully so, if things go wrong, the sky will fall, right? But the problem is it’s always the "if."
And like I sort of hinted at earlier on: with this CVE and with the information around it and how it affects lots of other web frameworks, not just .NET. And that’s the that’s the scary thing, other frameworks are involved, right? Not just .NET. Because there are other frameworks involved, it will become more and more well known, right? And so the malicious actors who are interested in breaking into your systems and stealing your data will either know about it or will be learning about it. And so you need to put that protection in place.
My worry is that in the AppSec… I know we’ve we’ve started the wrap up, but I just want to say this right: My worry is that in the AppSec space, there’s a lot of fear because, rightfully so, if things go wrong, the sky will fall, right? But the problem is it’s always the "if."
And like I sort of hinted at earlier on: with this CVE and with the information around it and how it affects lots of other web frameworks, not just .NET. And that’s the that’s the scary thing, other frameworks are involved, right? Not just .NET. Because there are other frameworks involved, it will become more and more well known, right? And so the malicious actors who are interested in breaking into your systems and stealing your data will either know about it or will be learning about it. And so you need to put that protection in place.
Hayden
Yes.
Jamie
Because you’re never gonna know.
Hayden
You’re never gonna know. And There’s going to be tools, you know, open source tools that test for this. You know, if there’s not a tool in Metasploit already, there probably will be very soon, you know.
So there will be malicious actors scanning for this vulnerability. You know, just bulk scanning IP addresses, trying to find, you know, what they can slip past.
So there will be malicious actors scanning for this vulnerability. You know, just bulk scanning IP addresses, trying to find, you know, what they can slip past.
Jamie
Yep.
Hayden
And then once once they identify a vulnerable system, they can start probing, find additional endpoints, achieve privilege escalation. Yeah.
Jamie
Yeah, it’s a scary time. It genuinely is deserving of the 9.9. I know that a lot of places receive CVE alerts that are quite high, and we’ve kind of become, it’s become normalised. That’s probably the best way to put it.
So it’s become normalised to just see a 9+ on a CVE and go, "yeah, but the rest were… it’s like the Scotty principle, right?" If I keep telling you it’ll take me six months to do it and then I do it in two hours, the next time I’d say it’s gonna take six months, you’re going to assume it’ll be done in two hours. Ergo, if all the CVE’s are nine, then nine is one, right? But this one, folks, genuinely, this one is super serious.
So it’s become normalised to just see a 9+ on a CVE and go, "yeah, but the rest were… it’s like the Scotty principle, right?" If I keep telling you it’ll take me six months to do it and then I do it in two hours, the next time I’d say it’s gonna take six months, you’re going to assume it’ll be done in two hours. Ergo, if all the CVE’s are nine, then nine is one, right? But this one, folks, genuinely, this one is super serious.
Hayden
Yeah, the the implications of this vulnerability are so wide-ranging, depending on how your application is constructed, and there’s no way for Microsoft or other actors in the. NET community to tell you, "hey, this application is vulnerable to this. Like th this is how this can happen." But it’s possible. And and it’s the unknown that makes this particularly particularly scary.
Jamie
Yep. Yep.
Well, Hayden, I know I said earlier on, but thank you for coming back and spending some time with us to talk about this because, yeah, it it is super important. Like I’m gonna go literally tomorrow, so in a few days time when this episode releases, the folks who are listening to it will know why I started shouting at them in the morning about, "we need to, seriously guys, let’s get this upgraded. Because we need to get this upgraded."
So yeah. Thank you so much for this, Hayden. I appreciate you a super busy person. But yeah, definitely go check out Hayden on his socials. He’s @UnixTerminal on most of the things, but he’s also on LinkedIn and, things like. And boxofcabled.dev for the website; because I’m doing your bit for you.
Well, Hayden, I know I said earlier on, but thank you for coming back and spending some time with us to talk about this because, yeah, it it is super important. Like I’m gonna go literally tomorrow, so in a few days time when this episode releases, the folks who are listening to it will know why I started shouting at them in the morning about, "we need to, seriously guys, let’s get this upgraded. Because we need to get this upgraded."
So yeah. Thank you so much for this, Hayden. I appreciate you a super busy person. But yeah, definitely go check out Hayden on his socials. He’s @UnixTerminal on most of the things, but he’s also on LinkedIn and, things like. And boxofcabled.dev for the website; because I’m doing your bit for you.
Hayden
Thank you, thank you. This is perfect. I’m smuggling requests through and you’re you’re repeating it for me.
Jamie
That’s it. That’s exactly it. No, that’s exactly what it is. You told me all of this information in our previous recording, and it’s come through, right? It’s been smuggled into this episode
Hayden
Yeah, exactly.
Jamie
Thank you ever so much, Hayden. Yeah folks, go upgrade your stuff.
Hayden
Thank you, Jamie.
Wrapping Up
Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.
Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.
And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.
But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.
I will see you again real soon. See you later folks.
Useful Links
- Understanding CVE-2025-55315: What CISOs, security engineers, and sysadmins should know
- ASP.NET Security Feature Bypass Vulnerability
- Funky chunks: abusing ambiguous chunk line terminators for request smuggling
- Understanding the worst .NET vulnerability ever: request smuggling and CVE-2025-55315
- Update your SDK and runtime
- Metasploit
- The Scottie Principle
- HeroDevs
- Supporting the show:
- Getting in touch:
- Podcast editing services provided by Matthew Bliss
- Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show
- Editing and post-production services for this episode were provided by MB Podcast Services