微軟在 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

Post a comment