嚴重等級 9.9 的 ASP.NET Core 資安漏洞 CVE-2025-55315
| | | 13 | |
微軟在 10/14 發佈了一則資安漏洞公告 CVE-2025-55315,其 CVSS (Common Vulnerability Scoring System) 漏洞嚴重等級直上 9.9、危險等級也高達 8.6。
起源是 ASP.NET Core 從 2.3 到 .NET 10 的 Kestrel 都存在一個安全漏洞,由於 Kestrel 對 HTTP Request Header 的檢查邏輯不夠周全,攻擊者有可能透過特殊設計的 HTTP 請求資料,由看似正常的請求挾帶惡意請求繞過安全檢查成功闖關。(這種手法又稱為 HTTP Request/Response Smuggling 走私)
一旦闖關成功,視應用程式的設計方式不同,攻擊者有機會略過權限管控、取得使用者登入憑證、竊取機密資料、竄改檔案內容、形成 DoS 攻擊... 等,雖然成功前題與系統設計有關,而這些對應到 CVSS 評分的機密性(C)、完整性(I)、可用性(A),考量最壞的狀況,都可視為高風險,讓嚴重度升高到 9.9。
【資安科普】CVSS 的嚴重性 Critical 分數通常對應一個最直接、最容易被利用的攻擊情境,一個 9.9 分的漏洞通常具備以下特徵:
- 攻擊向量 (AV): 網路 (Network) - 駭客可以從遠端透過網路發動攻擊。
- 攻擊複雜度 (AC): 低 (Low) - 不需要複雜的條件或技術即可成功利用。
- 所需權限 (PR): 無 (None) - 駭客不需要任何權限就能攻擊。
- 使用者互動 (UI): 無 (None) - 不需要使用者執行任何動作。
- 範疇 (S): 已變更 (Changed) - 漏洞的影響會超越原本的軟體元件,可能影響到整個作業系統。
- 機密性 (C)、完整性 (I)、可用性 (A) 影響: 皆為高 (High) - 能讓駭客竊取所有資料、竄改任何檔案,並讓系統完全癱瘓。
考慮最壞的狀況,攻擊者可以不需要密碼、不需要使用者點擊任何東西,就能從網際網路連上有漏洞的 ASP.NET Core Ketrel,偷資料改檔案並癱瘓整台伺服器,符合 9.9 標準。
(但依據 Microsoft 安全專家 Kevin Dorrans 的說法:給這個漏洞打最高分,是基於「最壞情況」的假設。這個最壞情況就是:攻擊者不僅能繞過安全機制,還能影響到系統的其他部分。但說實話,這種最壞情況發生的機率很低,除非你的程式碼夠低級,省掉原本該有的基本安全檢查。參考)
至於修補方式,依 ASP.NET Core 版本不同,做法不同。
- 若為 .NET 8 或更新版本,請從 Microsoft Update 安裝 .NET 更新,然後重新啟動應用程式或重新啟動電腦即可。
- 若為 ASP.NET Core 2.3,則必須更新 Microsoft.AspNet.Server.Kestrel.Core 套件到 2.3.6,然後重新編譯您的應用程式並重新部署。
- 若程式被編譯為獨立/單一檔案應用程式(--self-contained),則必須更新 .NET 版本、重新編譯應用程式並重新部署。
如何檢查目前的 .NET 版本是否安全?最簡單的做法是執行 dotnet --info,檢查 Microsoft.AspNetCore.App 的版本:

或是更簡潔的做法,用 dotnet --list-runtimes 只查 Runtime:(感謝讀者 Ike 分享)

(註:若是用 Docker 跑 ASP.NET Core,理論上重新編譯 Image 就會從 mcr.microsoft.com/dotnet/aspnet:X.0 抓最新版本,不放心的話可用 docker exec -it <container-name> /bin/bash 登入,再用 dotnet --info 檢查。延伸閱讀:Docker 排查偵錯常用 CLI 指令整理)
依 ASP.NET Core 版本,版本需升級到 2.3.6、8.0.21、9.0.10 以上。Visual Studio 2022 的部分,需更新到 17.10.20、17.12.13、17.14.17 以上。參考
CVE-2025-53315 affects ASP.NET Core Kestrel, allowing severe remote attacks; update .NET and related components to secure your system.
Comments
# by 居紫
dotent --info 寫錯了啦 XD
# by Jeffrey
to 居紫,Orz,已修正,謝~~
# by Reggie
雖然微軟沒有明確寫出來但懷疑.net 3.1 / 6 也是有這漏洞 因為微軟內部政策不會對EOL產品做進一步確認
# by Jeffrey
to Reggie,針對已 EOS 的產品不提供保固、維修、更新或安全修補是業界通則,也是企業遇到軟硬體 EOS 就被逼著升級的原因
# by Ike
使用 dotnet --list-runtimes 指令更簡捷
# by yoyo
若程式是self contained,如何確認dotnet版本?
# by Rico
另一個有趣的雷,我裝了sdk 8.0.21 (8.0.121)版本後,發現application都還是維持舊版 (8.0.8)。 細查才發現,因為sdk 8.0.8 的版本號是 8.0.402,所以用的時候dotnet自然覺得 402 > 121,就用數字大的版本... 後來仔細看才發現 8.0.21底下有三個版本,其中一個是 8.0.415.....真的是小雷
# by Rico
to yoyo 程式裡面紀錄 Environment.Version , System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription 這兩個取一就好
# by Jeffrey
to Ike,感謝分享,已補充於本文。
# by Kq
https://andrewlock.net/understanding-the-worst-dotnet-vulnerability-request-smuggling-and-cve-2025-55315/ 微軟工程師的部落格文章提到: 「And if you're using older versions of .NET Core? Well, then you can't patch… HeroDevs provide additional support for out-of-support versions of .NET (and have confirmed they'll be patching it in .NET 6), but this vulnerability is present in basically all versions of .NET Core as far as I can tell. I've personally tested down to .NET Core 3.0 and I can confirm that the vulnerability is there and there are no patches coming for you. The best thing to do is to update to a supported version of .NET. ⚠️ If you are running ASP.NET Core using <=.NET Core 3.0, .NET Core 3.1, .NET 5, .NET 6 (unless supported by HeroDevs), or .NET 7, then you are vulnerable, and there are no patches. You should update to a supported version of .NET as soon as possible. Ironically, if you're stuck on old .NET Framework Web Forms or MVC applications you are apparently not vulnerable.」 這漏洞是ASP.NET Core全版本都有的 但.NET 3.1、6無提供官方安全性更新
# by Alex
好奇,這個問題在.NET FRAMEWORK也會有相同問題嗎? 通常這種問題應該不會只有.net core發生
# by Jeffrey
to Alex, 問題在 Kestrel (輕量級 Web Server),ASP.NET Core 才會用到,.NET Framework 或 .NET 6+ Console/Desktop 不受影響。
# by fsyoung
這邊需要更正一下說法,ASP.NET Core 2.3 是針對跑在.netframework 上的 asp.net core 有提供更新修正 跑在 .net core 的是沒有辦法重新引用Microsoft.AspNet.Server.Kestrel.Core