微软这次发的是紧急安全更新，不是普通例行补丁。它修复了 ASP.NET Core 中 Microsoft.AspNetCore.DataProtection 10.0.0 到 10.0.6 的高危漏洞 CVE-2026-40372，最高严重性 9.1。重点受影响的是 macOS、Linux 及其他非 Windows 部署。
问题也不复杂：认证保护链路里的加密签名/HMAC 验证出了回归 bug。结果是，未认证攻击者在满足条件时可以伪造认证载荷，冒充高权限身份。更麻烦的是，补丁只能堵住新洞，未必能清掉旧账。若攻击者在漏洞窗口期已经骗到系统签发长期凭证，升级后这些凭证仍可能继续有效。
漏洞到底影响谁，别把范围说大了
这次不是“ASP.NET Core 全线沦陷”。焦点很窄，但足够危险：受影响的是 DataProtection 包，以及特定平台和装载路径。
| 项目 | 事实 | 你该怎么理解 |
|---|---|---|
| 漏洞编号 | CVE-2026-40372 | 高危，CVSS 9.1 |
| 受影响版本 | Microsoft.AspNetCore.DataProtection 10.0.0-10.0.6 | 升级目标是 10.0.7 |
| 重点受影响平台 | macOS、Linux、其他非 Windows | Windows 默认不在主要受影响范围内 |
| 根因 | 修复 10.0.6 解密失败问题时引入回归 bug | 不是新功能翻车，是修补过程埋雷 |
| 后果 | 可伪造认证载荷，取得高权限 | 前提是应用用了受影响包，且暴露相关路径 |
微软公开说明里有几个限制条件，得看准。
重点是那些在运行时实际加载了 10.0.6 的非 Windows 应用。尤其是在 .NET 10 默认启用 PrunePackageReference 后，包引用和运行时装载路径形成了特定组合，风险会落到线上。还有一部分非 Windows 应用或库，如果构建时拿到了受影响包的 net462 或 netstandard2.0 资产，也会中招。
Windows 默认不受影响，这点不能写错。原因不是 Windows 天生更稳，而是默认加密器不同，没有走到这条出问题的路径。平台差异才是关键变量。
对维护 ASP.NET Core 服务的开发者和平台工程师来说，眼下先查三件事：部署是不是非 Windows，运行时到底加载了哪个 DataProtection 版本，应用是否对外暴露认证相关端点。如果这三件里有两件答不上来，说明你现在连受影响范围都还没摸清。
为什么补丁不等于收尾
真正贵的不是发版，而是补救。
如果攻击者在漏洞窗口期里伪造了认证载荷，并成功拿到高权限身份，系统后面可能会继续给他签发合法凭证。比如持久会话令牌、刷新令牌、API key、密码重置链接。升级到 10.0.7，只能阻止新的伪造，不会自动让这些已签发的东西失效。
这就是认证事故最麻烦的地方。古人说“其亡也忽焉”，放在这里很贴切。认证平时像背景设施，出事时才发现它是承重墙。一旦“谁可以被相信”这件事被打穿，坏掉的就不是一个包，而是后面的授权、审计、恢复整条链。
所以补救至少包括三步：
- 升级到 Microsoft.AspNetCore.DataProtection 10.0.7
- 轮换 DataProtection key ring
- 审计并撤销漏洞窗口期内可能签发的长期凭证
很多团队会卡在第三步。因为这已经不是框架升级问题，而是运营问题、日志问题、流程问题。
谁会先动手？平台工程师会先安排升级和 key ring 轮换。安全团队会追日志，找漏洞窗口期里异常认证、越权访问和可疑令牌签发记录。业务团队如果依赖长期会话、邮件重置链接或对外 API key，往往还得准备强制失效、批量重登，甚至临时推迟一部分上线计划。补丁几分钟能发完，账可能要查几周。
目前没有公开证据表明已经出现大规模在野利用，这点要保持克制。可没有公开证据，不等于可以把它当成普通更新。认证一旦失守，代价通常滞后出现。
这次事故暴露了什么
我不太买账的一种说法是：这只是一次普通回归 bug。不是。
它至少说明一件事：跨平台框架更新里，最脆的地方往往不是算法，而是默认路径、平台分支和补丁链条。密码学原语没变，验证实现先出了问题。历史上浏览器、TLS 库、身份系统都反复演过这一幕，差别只在名字变了，结构没变。
这次更刺眼的一点是，问题是在处理 10.0.6 解密失败时被发现的。也就是说，事故不是外部新需求压出来的，而是修补过程自己带出来的安全后果。天下熙熙，皆为利来；放到工程管理里，就是发布节奏总在催着团队往前跑，验证深度却常常补不上。代码发得快，不等于信任链收得住。
如果你现在在管 ASP.NET Core 服务，我会更关注这几件事：
- 官方安全公告是否给出更细的受影响场景澄清
- 自家运行时是否实际装载 10.0.6，而不是只看项目文件里的声明版本
- 漏洞窗口期里是否签发过长期令牌、重置链接或对外 API key
- 升级后是否安排了 key ring 轮换和凭证撤销，而不是只改包版本
这里还有个现实约束要说清。不是所有团队都能轻松撤销长期凭证。B2B 系统、低频登录后台、嵌入第三方的 API key，一撤就是业务抖动。所以真正难的从来不是“有没有补丁”，而是你愿不愿意为恢复信任付出停机、重登、工单和客户沟通的成本。
这也是为什么 Windows 默认没中招，反而更值得看。它提醒你：安全事故很多时候不是“产品整体行不行”，而是默认实现、平台差异和测试覆盖是不是踩到了最危险的交叉点。看上去像一次小范围 bug，打穿的却是最贵的那层东西——认证。