背景

在2025年10月的微軟補丁星期二更新中，一個針對 ASP.NET Core 的漏洞 CVE-2025-55315 引起了安全社區的高度關注。該漏洞被美國國家漏洞數據庫 (NVD) 評定為 CVSS 3.1 基礎分 9.9 (高危)，這是一個極其罕見的高分，預示著其巨大的潛在風險 。

CVSS 9.9 分的嚴重性是什么概念？

為了準確理解 9.9 分的嚴重級別，我們可以將其與歷史上一些著名的漏洞進行對比：

• Log4Shell (CVE-2021-44228): 這個席卷全球的 Java 日志庫漏洞，因其影響范圍廣、利用難度低，獲得了完美的 10.0 分 。
• Shellshock (CVE-2014-6271): 這個存在于 Bash shell 中的嚴重漏洞，允許遠程命令執行，其 CVSS v3.1 評分為 9.8 分 。
• Heartbleed (CVE-2014-0160): 這個曾導致大規模數據泄露的 OpenSSL 漏洞，雖然影響巨大，但其 CVSS v3.1 評分僅為 7.5 分 。

通過對比可見，CVE-2025-55315 的 9.9 分，已將其置于與 Log4Shell 和 Shellshock 同等級別的嚴重威脅行列，需要所有.NET 開發者和運維團隊給予最高優先級的關注。

微軟安全項目經理 Barry Dorrans 甚至直言，這個漏洞的 CVSS 評分是“我們有史以來最高的” ，并不是危言聳聽。

官方鏈接參考:

• NVD 漏洞詳情: https://nvd.nist.gov/vuln/detail/CVE-2025-55315
• 微軟安全更新指南: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55315
• GitHub Issue 討論: https://github.com/dotnet/aspnetcore/issues/64033

CVE-2025-55315漏洞是什么？

簡單說，這是一個 HTTP 請求走私 (HTTP Request Smuggling, CWE-444) 漏洞 。它發生在 ASP.NET Core 的心臟——Kestrel Web 服務器中。攻擊者可以發送一個“畸形”的 HTTP 請求，讓你的前端代理（比如 Nginx、負載均衡器）和后端的 Kestrel 服務器對這個請求的“邊界”產生誤解，從而把惡意請求“走私”進去，繞過你的所有安全檢查 。

受影響范圍

以下.NET版本均受此漏洞影響 ：

• .NET 10: ASP.NET Core 10.0.0-rc.1.25451.107 及更早版本。
• .NET 9: ASP.NET Core 9.0.9 及更早版本。
• .NET 8: ASP.NET Core 8.0.20 及更早版本。
• .NET Core 2.x: 引用了 Microsoft.AspNetCore.Server.Kestrel.Core NuGet 包 2.3.0 及更早版本。

可以看到這個漏洞影響范圍極廣，從古老的.NET Core 2.3 到最新的.NET 8、.NET 9 乃至.NET 10 預覽版，幾乎是“全家桶”式的淪陷 。
.NET 3/4/5/6/7 未提及不是因為沒問題，只是因為官方已經不再維護了，有bug也不會修復，不想升sdk可以換成https://docs.herodevs.com/net 的鏡像。

修復措施

微軟官方明確指出，不存在任何緩解措施或臨時解決方案 。唯一的修復途徑是升級
對于.NET 8, 9, 10 項目: 升級至最新的.NET SDK 版本。
對于.NET Core 2.x 項目: 將 Microsoft.AspNetCore.Server.Kestrel.Core NuGet 包的引用更新至 2.3.6 或更高版本 。

什么是HTTP 請求走私？

HTTP 請求走私是一種利用 Web 架構中前后端服務器對 HTTP 請求邊界解析不一致的攻擊技術。在一個典型的 Web 架構中，前端代理（如反向代理、CDN）會通過一個持久的 TCP/TLS 連接，將來自多個用戶的請求“管道化”地轉發給后端 Kestrel 服務器 。為了正確地分割這些請求，前后端必須對每個請求的結束位置達成共識。
HTTP/1.1 規范提供了兩種定義請求體長度的方式：Content-Length 和 Transfer-Encoding: chunked。規范規定，當兩者同時存在時，Transfer-Encoding 頭的優先級更高 。然而，并非所有服務器實現都嚴格遵守此規則，或在處理被混淆、格式不規范的頭時行為不一，這就為攻擊創造了條件 。

攻擊者可以構造一個讓前端和后端產生不同解析結果的請求，導致一部分數據被后端服務器視為下一個獨立請求的開始。這個被“走私”的請求由于未經過前端代理的審查，可以繞過訪問控制、WAF 規則等安全措施 。

這對我們開發者來說是個巨大的盲區。因為無論你在中間件里寫了多么完美的授權 [Authorize] 和驗證邏輯，被走私的請求都能完美繞過，因為它在 Kestrel 眼里，就是一個全新的、合法的請求。

如何復現？

社區里已經有大神放出了復現這個漏洞的 PoC (Proof of Concept) 代碼，比如這個 GitHub 倉庫：sirredbeard/CVE-2025-55315-repro。該程序通過原始 TCP 套接字向一個本地 Kestrel 服務器發送構造的畸形 HTTP 請求，以驗證其解析行為。

這個程序做的事情很簡單：
在本地 5000 端口啟動一個最基礎的 Kestrel 服務器。
用原始的 TCP 套接字（Socket）連接這個服務器，發送兩個精心構造的、畸形的 HTTP 請求。
檢查服務器的響應。在打過補丁的環境下，服務器應該拒絕這些畸形請求，返回 400 Bad Request。如果服務器返回了 200 OK，說明它錯誤地處理了請求，漏洞就存在。

讓我們聚焦于兩個測試函數，它們是揭示漏洞本質的關鍵。

測試一：MultiReadWithInvalidNewlineAcrossReads
第一個測試的騷操作，就是模擬了一個極其刁鉆的網絡情況：它把一個本該完整的 \r\n (回車換行) 拆分到兩個 TCP 包里發送。

// 關鍵請求片段
var fragments1 = new List<string>
{
    //... headers...
    "1;\r" // 第一個包發送了塊大小和回車符(CR)
};
//... 發送 fragments1...
await Task.Delay(50); // 模擬網絡延遲
var fragments2 = new List<string>
{
    "\n" // 第二個包發送換行符(LF)
};
//... 發送 fragments2...

根據 HTTP/1.1 的分塊傳輸編碼（Chunked Transfer Encoding）規范，每個數據塊的大小定義后面必須緊跟一個完整的 CRLF (\r\n)。這個測試故意將 CRLF 拆開，模擬了網絡分包的極端情況。

• 修復后的 Kestrel：會嚴格遵守規范。當它讀到 1;\r 后，發現流暫時結束了，但沒有等到預期的 \n。在下一個包 \n 到達后，它能正確地將兩者拼接，但依然會識別出這是一個跨數據包的、不規范的分塊頭，因此拒絕請求，返回 400 Bad Request。
• 有漏洞的 Kestrel：對這種邊界情況的處理過于“寬容”。它可能會錯誤地解析這個被拆分的 CRLF，或者在處理緩沖區時出現邏輯錯誤，最終接受了這個畸形的請求，返回 200 OK。

測試二：InvalidNewlineInFirstReadWithPartialChunkExtension
這個測試則更直接，它發送了一個只用 \n 作為換行符的分塊頭，這同樣不符合 RFC 規范。

// 展示請求的關鍵部分
var fragments = new List<string>
{
    "GET / HTTP/1.1\r\n",
    "Host: localhost\r\n",
    "Transfer-Encoding: chunked\r\n",
    "\r\n",
    "1;\n" // 注意這里！直接使用了 LF (\n) 而不是 CRLF (\r\n)
};

HTTP 協議明確規定行結束符是 CRLF。只用 LF 是不規范的。

• 修復后的 Kestrel：會識別出這是一個無效的行結束符，直接拒絕請求，返回 400 Bad Request。
• 有漏洞的 Kestrel：再次表現出它的“寬容”，接受了這個不規范的請求。

通過對 PoC 代碼的分析，可以得出結論：CVE-2025-55315 的根源在于 Kestrel 的 HTTP/1.1 解析器在處理分塊傳輸編碼 (Chunked Transfer Encoding) 時，對行結束符的處理過于寬松，接受了不符合 RFC 規范的畸形輸入。
正是這種對協議規范的“寬容”，導致了 Kestrel 與嚴格遵守規范的前端代理之間產生了致命的解析差異，從而為 HTTP 請求走私攻擊打開了通道。

我在github上找到了官方的修復PR（Fix chunked request parsing），從這里能大致看出之前是只判斷 == '\n', 修復的PR更嚴格了

潛在影響與攻擊場景

一個成功的請求走私攻擊，其影響遠不止于簡單的請求偽造。以下是一些針對典型 ASP.NET Core 應用的真實攻擊場景：

• 場景一：繞過訪問控制，訪問內部接口 攻擊者以普通用戶身份認證，然后走私一個指向高權限接口（如 /admin/users）的請求。前端代理僅審查外部的合法請求并放行。當這個被走私的請求到達 Kestrel 時，它會被附加到連接池中下一個請求的前面。如果下一個請求來自一位已認證的管理員，那么這個惡意請求就可能在管理員的會話上下文中被執行，從而實現權限提升。

• 場景二：會話劫持與數據竊取 攻擊者走私一個不完整的 POST 請求。當下一個用戶的合法請求（包含其 Cookie 或 Authorization 頭）到達時，該用戶的整個請求可能被 Kestrel 錯誤地附加為攻擊者走私請求的 Body。如果攻擊者走私的請求被設計為將接收到的數據外傳，他就能成功竊取到受害用戶的會-話憑證或敏感數據。

• 場景三：Web 緩存投毒 (Web Cache Poisoning) 如果應用前端部署了緩存層（如 CDN），攻擊者可以利用此漏洞進行緩存投毒 。攻擊者走私一個請求，該請求會觸發后端應用返回一個惡意響應（例如，包含惡意 JavaScript 的頁面），并將其與一個會被緩存的熱門資源（如主頁或某個 JS 文件）的 URL 關聯。此后，所有請求該資源的用戶都將收到被投毒的惡意內容。

長期加固策略

除了立即應用補丁，還應考慮通過架構層面的改進來提供縱深防御，以抵御未來可能出現的類似漏洞。

• 端到端使用 HTTP/2 HTTP/2 協議從根本上改變了請求的傳輸方式，它使用確定性的二進制分幀層來界定請求，不再依賴 Content-Length 或 Transfer-Encoding 頭，因此天然免疫經典的請求走私攻擊 。應盡可能配置前端代理與 Kestrel 后端之間使用 HTTP/2 進行通信。
• 規范化模糊請求 配置前端代理（如 Nginx, HAProxy, Azure Application Gateway 等），在將請求轉發到后端之前對其進行“規范化”處理。例如，拒絕任何同時包含 Content-Length 和 Transfer-Encoding 頭的請求，或剝離所有不必要的頭信息 。

結論

CVE-2025-55315 是 ASP.NET Core 核心組件中的一個高危漏洞，其 9.9 的 CVSS 評分客觀反映了其對應用安全構成的嚴重威脅。鑒于其影響范圍廣泛且利用門檻較低，所有使用受影響版本.NET 的團隊都應立即采取行動，識別并修復環境中的所有相關資產。

此次事件也再次提醒我們，現代應用安全是一個全棧挑戰。開發者不僅要關注業務邏輯代碼的安全性，還必須對底層協議、Web 服務器到基礎設施的每一個層面有充分的理解和保護。安全不僅是業務邏輯層面的事，更是貫穿整個技術棧的挑戰。從網絡協議到 Web 服務器，再到我們的應用程序代碼，任何一個環節的疏忽都可能導致整個系統的崩潰。