史诗级漏洞警报：ASP.NET Core 被曝 CVSS 9.9 分漏洞，几乎所有.NET 版本无一幸免！
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更严格了
image
潜在影响与攻击场景
一个成功的请求走私攻击，其影响远不止于简单的请求伪造。以下是一些针对典型 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 服务器，再到我们的应用程序代码，任何一个环节的疏忽都可能导致整个系统的崩溃。