背景

在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 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 请求走私攻击打开了通道。

潜在影响与攻击场景

一个成功的请求走私攻击，其影响远不止于简单的请求伪造。以下是一些针对典型 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 服务器，再到我们的应用程序代码，任何一个环节的疏忽都可能导致整个系统的崩溃。

史诗级警报：ASP.NET Core 被曝 CVSS 9.9 分漏洞，几乎所有.NET 版本无一幸免！

背景