Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability #64475
Replies: 87 comments
-
|
In order to, hopefully, address any questions, I want to explain that CVSS score of 9.9, our highest ever. Let's examine why. The bug enables HTTP Request Smuggling, which on its own for ASP.NET Core would be nowhere near that high, but that's not how we rate things... Instead, we score based how the bug might affect applications built on top of ASP.NET. Request Smuggling allows an attacker to hide an extra request inside an another, and what that hidden request can do is very application specific. The smuggled request could cause your application code to
But we don't know what's possible because it's dependent on how you've written your app. Thus, we score with the worst possible case in mind, a security feature bypass which changes scope. Is that likely? No, probably not unless your application code is doing something odd and skips a bunch of checks that it ought to be making on every request. However please go update. Finally, to try to answer some frequent questions in advance:
|
Beta Was this translation helpful? Give feedback.
-
It would be useful to know what that is. Also, am I correct in assuming that applications running in IIS are not vulnerable? |
Beta Was this translation helpful? Give feedback.
-
It's totally application dependent unfortunately.
That's a question for the Windows HTTP.SYS folks. I can't speak for them unfortunately. |
Beta Was this translation helpful? Give feedback.
-
Right, but quoting a little less selectively:
It would be know what "doing something odd" is. That does sound like it is likely not something that happens with a LOB standard Razor Web app but rather if you're modifying the HTTP pipeline with custom middleware or using Yarp or similar. I may have ten or more applications to patch so it would be very useful to know what to check for. If the conclusion is "every ASP.NET Core app is likely to be vulnerable" then the text is only confusing.
I'm asking because the patched library appears to be Kestrel. |
Beta Was this translation helpful? Give feedback.
-
So things like authentication, server side http calls, updating databases based on information in an http request. Basically anything that does something with a request could be problematic. But, for example, an application that just appends to a log, no authentication, and the log truncates, would be vulnerable to missing real log entries. An app that does authentication and has access rules based on the authentication may be vulnerable to elevation of privilege, if it's not checking the identity at the point of trying to do something that needs admin rights. Note that this is personal opinion at this point, and not official Microsoft opinion.
Ah! Got you. We know Kestrel was vulnerable, we left looking at and evaluating http.sys, which IIS hosts atop of to Windows, as they own that component. I can't speak for them. |
Beta Was this translation helpful? Give feedback.
-
|
Am I correct in assuming that a self-contained ASP.NET Core application running in IIS is not vulnerable, assuming that IIS is not vulnerable? Or, in other words: Is this vulnerability strictly isolated to the Kestrel webserver, and not a general vulnerability within ASP.NET Core? |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, that may be wrong in general. I'm running a web application, IIS InProcess - hosted, no Kestrel used. But I saw a bug creating a notification mail via FirstChanceHandler: So Kestrel.Core.Internal.Infrastructure.StringUtilities is used, but the project doesn't use Kestrel. If the bug is in such code blocks, it may affect IIS-hosted applications. Because of own incomplete errors, I don't know which method or property call created that exception. Must be something reading headers, query string or form elements to create a notification mail. |
Beta Was this translation helpful? Give feedback.
-
Yes, I think that's a reasonable way to put it. |
Beta Was this translation helpful? Give feedback.
-
Every bug is a critical security vulnerability in this world. If they are writing their app like this then the App has the critical CVE not the library. Just because you can write this code it does not mean that |
Beta Was this translation helpful? Give feedback.
-
|
Does it assume the gateway/proxy in front of the application is also vulnerable? If the gateway/proxy normalizes the request per strict http 1.1 and only send the normalized requests to upstream, will the upstream ASP.NET Core application still suffer from such attack? |
Beta Was this translation helpful? Give feedback.
-
We can't assume there's a gateway in front of an application. If such a gateway manages to remove smuggled requests, then the app could never see it, so there wouldn't be a problem. |
Beta Was this translation helpful? Give feedback.
-
This is true, which is why I said it's app dependent. But if we lowered the score, because really for asp.net it doesn't cross trust boundaries it would leave folks vulnerable if their apps were written in ways that exposed them to parsing smuggled requests badly. That would be a disservice to our users, hence the high score. |
Beta Was this translation helpful? Give feedback.
-
|
I was not familiar with the concept of request smuggling, and in the context of that unfamiliarity it wasn't clear to me how to go about knowing if an app was vulnerable. After reading, my understanding is that a scenario that would create this CVE might be:
The attacker sends a malicious request. It is formed such that: Someone please correct me if I am mistaken, but the big thing to look for is any .net app that relies on an external server for any form of validation or authorization. Middleware "simple" servers that do their own login logic should not be impacted? |
Beta Was this translation helpful? Give feedback.
-
|
I recall YARP relying heavily on Kestrel infrastructure so could the logic built-on top of it also be potentially affected by this? |
Beta Was this translation helpful? Give feedback.
-
If you update the runtime on your servers Yarp will get the update too. They don't need a separate CVE, or to rebuild, as they're not running atop framework, nor are they self contained. |
Beta Was this translation helpful? Give feedback.
-
|
@JuergenAuer I wont tell you if that will 100% solve it, but that looks like you're on the right track. I'd suggest someone stuck in a lower version test before and try to reproduce with burpsuite repeater. If vulnerable, You should be able to see 2 responses come back like: 
|
Beta Was this translation helpful? Give feedback.
-
@JuergenAuer absolutely not! Although there are other request smuggling approaches that rely on the Content-Length header, it is not implicated in this particular vulnerability. |
Beta Was this translation helpful? Give feedback.
-
Looks like the problem is a pure IIS problem. Installed ncat,
with file saved as ASCII and these empty lines produced the expected output: Used the code from #64033 (comment) I see two results, two http headers, one without html, the other with html. PS: @egraff : Yes, it's an IIS problem. Can't be fixed via an application behind IIS. |
Beta Was this translation helpful? Give feedback.
-
|
IIS has a flag you can set to mitigate.
Get Outlook for Android<https://aka.ms/AAb9ysg>
[cid:insurity-email-signature-2024_e538b379-188c-4235-a9ab-964cc780ac9d.jpg] Adam Davis | CSSLP |
Director, Application Security
T 438-701-2533
[cid:eii2025-signature_efe8207f-b665-489d-8040-b4f64c17be60.jpg]<https://insurity.com/excellence>
<https://insurity.com/excellence>
<https://insurity.com/excellence>
<https://excellence.insurity.com/excellence/p/1>
…________________________________
From: JuergenAuer ***@***.***>
Sent: Friday, October 24, 2025 6:23:30 PM
To: dotnet/aspnetcore ***@***.***>
Cc: Adam Davis ***@***.***>; Comment ***@***.***>
Subject: Re: [dotnet/aspnetcore] Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability (Issue #64033)
[https://avatars.githubusercontent.com/u/65248690?s=20&v=4]JuergenAuer left a comment (dotnet/aspnetcore#64033)<#64033 (comment)>
but that looks like you're on the right track
Looks like the problem is a pure IIS problem.
Installed ncat,
ncat my-online-ip 80 < command-good.txt
with file saved as ASCII and these empty lines
GET / HTTP/1.1
Host: mydomain.de
produced the expected output:
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://mydomain.de/
Server: Microsoft-IIS/10.0
X-Powered-By: ARR/3.0
X-Powered-By: ASP.NET
Date: Fri, 24 Oct 2025 22:11:58 GMT
Content-Length: 0
Used the code from #64033 (comment)<#64033 (comment)>
POST / HTTP/1.1
Host: mydomain.de
Content-Length: 13
Transfer-Encoding: chunked
0
GET / HTTP/1.1
Host: localhost
X:
I see two results, two http headers, one without html, the other with html.
HTTP/1.1 400 Bad Request
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Fri, 24 Oct 2025 22:09:29 GMT
Content-Length: 24
Unzulässige AnforderungHTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 24 Oct 2025 22:09:29 GMT
Connection: close
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request</h2>
<hr><p>HTTP Error 400. The request is badly formed.</p>
</BODY></HTML>
PS: @egraff<https://github.com/egraff> : Yes, it's an IIS problem. Can't be fixed via an application behind IIS.
—
Reply to this email directly, view it on GitHub<#64033 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZOCGW7QRXQQY5HKTCEGANT3ZKRGFAVCNFSM6AAAAACJFQCKSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBVGA4TSMJTGU>.
You are receiving this because you commented.Message ID: ***@***.***>
_____________________________________________________________________________________________________
The information contained in this e-mail message is intended only for the personal and confidential use of the intended recipient(s). This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
_____________________________________________________________________________________________________
~~~Insurity~~~
|
Beta Was this translation helpful? Give feedback.
-
|
How can this issue be resolved in an Azure Function running in a container? We are using the mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0 runtime image and mcr.microsoft.com/dotnet/sdk:8.0 as build, now the Docker build output includes the vulnerable Microsoft.AspNetCore.Server.Kestrel.Core version 2.2.0, which causes the Aqua scan to fail. When will Microsoft release a patch for this vulnerability? Or any alternative way to fix this issue? |
Beta Was this translation helpful? Give feedback.
-
Functions is behind the same proxy setup as Azure Web Applications, so it's protected in the same way. Your Microsoft.AspNetCore.Server.Kestrel.Core 2.2.0 is something I saw reported elsewhere and forwarded to the functions team. Whilst it's not a false positive, the file is there, it's never used, not by your code, not by theirs, and they're working on getting it removed. |
Beta Was this translation helpful? Give feedback.
-
|
The Azure team has released an update to the HTTP load balancer infrastructure to mitigate the CVE-2025-55315. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I wrote a blog post trying to explain this vulnerability in more detail: https://andrewlock.net/understanding-the-worst-dotnet-vulnerability-request-smuggling-and-cve-2025-55315/ It's a pretty long read, but I have seen a lot of confusion in this thread and elsewhere about the specific details of this vulnerability (e.g. it's not a It covers:
|
Beta Was this translation helpful? Give feedback.
-
|
Im running Azure Functions with .NET 8 in isolated worker model using App Service Plan, do I need to take any action? From reading your post @andrewlock it seems like it is handled in Azure (https://azure.github.io/AppService/2025/10/20/dotnet-on-windows.html) right? |
Beta Was this translation helpful? Give feedback.
-
Based on the linked document I assume you're ok, but I'd recommend patching anyway to be on the safe side |
Beta Was this translation helpful? Give feedback.
-
|
For those asking about IIS, see https://msrc.microsoft.com/update-guide/en-US/vulnerability/ADV200008 for guidance. |
Beta Was this translation helpful? Give feedback.
-
|
@jiruss that document is 5 years old, and as I understand it is related to a different request smuggling vulnerability. I would be very surprised if it mitigates the issue. As I mentioned at the end of my post, I believe I'm able to trigger the vulnerability with some local testing using WSL and IIS: # Make sure IIS is listening and serving something:
curl http://192.168.0.1:80
# Send an HTTP request with an invalid chunk extension, to the Windows side and see
# if it times out or if it's rejected with a 400... It times out 🙁 (Make sure to use
echo -e "GET / HTTP/1.1\r\nHost:\r\nTransfer-Encoding: chunked\r\n\r\n1;\n" \
| nc 192.168.0.1 80Just to be sure, I tried setting the |
Beta Was this translation helpful? Give feedback.
-
|
@andrewlock Interestingly enough, when I tried your test on my IIS server, the request gets caught by http.sys with 400 bad request WITHOUT setting the flag I mentioned above so I am not sure what you are hitting C:\Users\jiruss>echo GET / HTTP/1.1\r\nHost:\r\nTransfer-Encoding: chunked\r\n\r\n1; | ncat 192.168.1.26 80 Bad RequestHTTP Error 400. The request is badly formed. |
Beta Was this translation helpful? Give feedback.
-
|
@jiruss You're missing the |
Beta Was this translation helpful? Give feedback.
-
|
"ill there be a newer version of the we're referencing the former, and i'm not certain that the latter is actually picked (probably not super high prio, since we only use it in playwright tests) |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 10.0 , ASP.NET Core 9.0 , ASP.NET Core 8.0, and ASP.NET Core 2.3. This advisory also provides guidance on what developers can do to update their applications to address this vulnerability.
Inconsistent interpretation of http requests ('http request/response smuggling') in ASP.NET Core allows an authorized attacker to bypass a security feature over a network.
Discussion
Discussion for this issue can be found at dotnet/announcements#371
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
Affected Packages
The vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below
ASP.NET Core 10
ASP.NET Core 9
ASP.NET Core 8
Advisory FAQ
How do I know if I am affected?
If you have a runtime or SDK with a version listed, or an affected package listed in affected software or affected packages, you're exposed to the vulnerability.
How do I fix the issue?
dotnet --infocommand. You will see output like the following;If you're using .NET 8.0, you should download and install .NET 8.0.21 Runtime or .NET 8.0.318 SDK (for Visual Studio 2022 v17.10 latest update) from https://dotnet.microsoft.com/download/dotnet-core/8.0.
If you're using .NET 9.0, you should download and install .NET 9.0.10 Runtime or .NET 9.0.111 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/9.0.
If you're using .NET 10.0, you should download and install .NET 10.0.0-rc.2.25476.107 Runtime or .NET 10.0.100-rc.2.25476.107 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/10.0.
If you're using Microsoft.AspNetCore.Server.Kestrel.Core nuget package, update to the latest version 2.3.6 using either of the following methods:
Using the NuGet Package Manager UI in Visual Studio:
- Open your project in Visual Studio.
- Right-click on your project in Solution Explorer and select "Manage NuGet Packages..." or navigate to "Project > Manage NuGet Packages".
- In the NuGet Package Manager window, select the "Updates" tab. This tab lists packages with available updates from your configured package sources.
- Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version.
- Click the "Update" button.
Using the NuGet Package Manager Console in Visual Studio:
- Open your project in Visual Studio.
- Navigate to "Tools > NuGet Package Manager > Package Manager Console".
- To update a specific package to its latest version, use the Update-Package command:
Code:
Using the .NET CLI (Command Line Interface):
Open a terminal or command prompt in your project's directory.
To update a specific package to its latest version:
Code:
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET 8.0, .NET 9.0 or .NET 10.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Acknowledgement
Sid
CVE-2025-55315
Revisions
V1.0 (October 14, 2025): Advisory published.
Version 1.0
Last Updated 2025-10-14
Beta Was this translation helpful? Give feedback.
All reactions