.NET 悬崖：当.NET 8和.NET 9停止接收补丁时会发生什么

简而言之

一个日期。两个框架。此后无需任何补丁。

2026年11月10日，微软将同时终止对.NET 8（当前的长期支持版本）和.NET 9（当前的标准支持版本）的支持。这绝非一个可以拖延的日程安排上的巧合。这一天，针对所有仍在这些系统上运行的应用程序，两条补丁发布通道都将永久停止。

‍

如果贵组织在生产环境中运行的是.NET 8或.NET 9，本指南将详细说明“支持终止”实际上会带来哪些变化，为何受监管团队往往首先通过合规和保险方面感受到其影响，而非数据泄露事件，以及两条切实可行的应对路径：迁移至.NET 10，或通过持续的安全支持来过渡。

‍

本指南涵盖的内容包括：所谓“支持终止”究竟会带来哪些实际影响；为何合规风险和保险风险通常会在实际数据泄露发生之前就显现出来；一个未打补丁的框架如何加剧其上所有构建系统的风险；以及两条避免坠入深渊的途径，其中包括一项90天计划。

• 2026年11月10日：微软为.NET 8和.NET 9发布安全补丁的最后一天
• 两个框架在同一天终止支持：一个 LTS 版本和一个 STS 版本同时终止支持
• 在.NET 6停止支持后披露的56个CVE，已在.NET 6的NES中修复

‍

为什么这个截止日期不同寻常

LTS 和 STS 版本通常不会同时过期。

微软的.NET 发布周期旨在分散风险：像.NET 8这样的长期支持（LTS）版本可获得三年的补丁支持，而像.NET 9这样的标准支持（STS）版本则为18个月，因此STS版本会在其前一个LTS版本发布前六个月停止支持。

‍

2026年11月10日是该偏移量首次消失的日期。.NET 8（2023年11月发布）和.NET 9（2024年11月发布）都在同一天达到了支持期限上限，因为微软于2025年9月将STS支持期限从18个月延长至24个月，该政策自.NET 9开始生效。 这使得.NET 9的支持终止日期从2026年5月12日推迟至.NET 8的三年支持周期结束之日。

‍

实际效果是，那些通过同时运行最近两个版本来分散风险的团队（这曾是一种常见且合理的策略），在本周期内将无法获得任何错开部署带来的好处。 无论您当前的.NET 8/.NET 9部署情况如何，都需要针对同一日期制定统一的计划。而且，这绝不会是最后一次。根据24个月的政策，下一个STS版本.NET 11预计将于2028年11月与.NET 10同步结束支持。

‍

支持终止本身并非新鲜事： .NET 6 于 2024 年 11 月 12 日自动终止支持，比.NET 7 晚了六个月。那些将其视为“软截止日期”的团队——他们以为微软或生态系统会延长支持期限，或者认为已终止支持的运行时环境上未修补的 CVE 不会引起关注——在接下来的一年里，不得不向审计机构、保险公司，甚至在某些情况下向客户解释这一未解决的风险。 2026年11月10日将是同样的截止日期，但受影响范围将扩大一倍。

“停止支持”并不意味着什么

这并不意味着.NET 8或.NET 9会停止运行。应用程序仍会像前一天一样正常运行。正因如此，内部人员往往容易低估这一截止日期的影响：11月11日当天，表面上看不出任何异常。真正发生的变化更为隐蔽，而对于大多数受监管的组织而言，这些变化带来的影响却更为深远。下文将对此进行详细说明。

‍

11月10日究竟会有什么变化

补丁的发布停了，但漏洞依然存在。

安全研究人员和攻击者并不会因为微软停止为.NET 漏洞发布补丁就停止寻找这些漏洞。影响.NET 8和.NET 9代码路径的新CVE仍会不断被发现。唯一的变化是，这些漏洞不再有官方修复程序。 11月10日本身就是“补丁星期二”，而微软通常会在某个版本的最后一个“补丁星期二”发布该版本的最终更新。此后披露的任何漏洞都不会获得微软的修复。HeroDevs的安全团队将此称为“永恒之日”问题：一旦某个运行时达到生命周期终止，针对它新披露的每个漏洞都将无从修复。

‍

补丁流不仅涵盖运行时。.NET 8 或.NET 9 的安装由四个部分组成，这四个部分都将停止接收修复程序：.NET 运行时、ASP.NET Core 共享框架、用于 WPF 和 Windows Forms 的 Windows 桌面运行时，以及.NET SDK（包括 MSBuild）。.NET 6 展示了支持终止后的具体情况。HeroDevs为.NET 6在NES中发布的修复程序已应用于上述所有组件：运行时中修复了WebSocket解压拒绝服务漏洞和Linux诊断套接字暴露问题（6.0.44），Kestrel中修复了HTTP/3控制流拒绝服务漏洞（6.0.45）， WPF 字体和字形渲染中的堆内存越界写入（6.0.44），以及 SDK 中针对 MSBuild 下载文件名伪造的修复和 dotnet 监视器的来源检查（6.0.45 和 6.0.46）。

四项实际后果

• 漏洞扫描工具会不断向您发出警报，且这种情况将持续下去。您的SCA和漏洞管理工具将继续发现针对.NET 8/9的CVE，而且与受支持的运行时不同，这些漏洞将永远不会转为“已修复”状态。11月10日之后的每次扫描都会使积压的漏洞清单不断增加。
• 扫描工具也可能遗漏实际存在的漏洞。微软不会为已停止支持的.NET 版本发布CVE或补丁，因此新的CVE仅列出受影响的受支持版本，而根据该记录进行匹配的扫描工具在.NET 8或.NET 9上将无法检测到任何问题。 2025年10月14日披露的CVE-2025-55315（ASP.NET Core Kestrel服务器中评分9.9的请求走私漏洞）便是典型案例：.NET 6虽存在该漏洞，但CVE未将其列入受影响列表，微软也未发布补丁。三天后，HeroDevs在NES中发布了针对.NET 6.0.39的修复程序。
• 严重性评分并非一成不变。一个在 CVSS 4 或 5 版本中看似优先级较低的 CVE，如果被添加到 CISA的“已知被利用漏洞”（KEV）目录中，或者其EPSS利用概率评分骤升，就可能在一夜之间变得紧急；而这种重新分类可能发生在初始披露数年之后。在受支持的运行时环境中，这只会触发一个补丁周期。 而在已停止支持（EOL）的运行时环境中，则无补丁可应用。
• 低严重性的发现可能连锁引发高严重性的问题。某个组件中一个看似微不足道的问题，一旦与您技术栈中的其他因素结合，就可能成为多步骤攻击路径中的关键环节。单个 CVSS 评分永远无法反映这种组合的影响，只有您自己的风险分析才能做到这一点，而审计人员也越来越期望看到这种分析的书面记录。

这并非.NET 独有的现象。每一个开源生态系统都存在大量已停止维护的软件包，这些软件包存在已知的CVE漏洞，且上游不会提供修复程序。.NET 8和.NET 9即将于同一天，以企业级规模将另外两个广泛使用的运行时环境加入到这一列表中。

‍

这实际上首先会带来什么影响

账单通常是在审计或续约时才需要支付，而不是在发生违规时。

大多数团队将产品生命周期末期（EOL）风险理解为“我们可能会遭到黑客攻击”。对于受监管的组织而言，更迫在眉睫的风险在于：悄无声息地运行已不再受支持的软件，会使您在不知不觉中违反必须遵守的合规框架，而这一问题往往会在您无法掌控的时间点被发现。

网络保险遵循同样的逻辑

保险公司一直直接对这一风险进行定价。Coalition发布的《2023年网络安全索赔报告》显示，无论公司规模大小，运行已到生命周期末期的软件的组织遭遇安全事件的概率高出三倍；此外，即使仅存在一个未解决的严重漏洞，被保险人提出索赔的概率也会增加33%。

‍

保险公司可以通过多种途径拒绝或限制与已停产（EOL）软件相关的索赔：无论是否存在过失均适用的指定除外责任；若申请材料中对安全控制措施存在误述，则可撤销保单；以及当数据泄露涉及不再受支持的组件时，保单中的保证条款将导致保险责任失效。此外，许多保单仅提供恢复至事故发生前状态的资金支持，而不涵盖系统升级，因此“数据泄露后我们再修复”并非保险公司愿意承担费用的策略。

‍

摆脱困境的办法

审计师和承销商并不要求你的财务状况是最新的，而是要求你的财务状况有充分依据。

这是大多数团队在截止期限的压力下容易忽略的一个细节：上述框架中实际上都没有明确规定“必须使用最新版本”。它们要求的是，无论运行什么版本，都必须能够证明获得供应商的支持以及对补丁更新的承诺。这一门槛比完全迁移要低，而供应商支持服务正是为了帮助客户跨越这一门槛而设计的。

‍

承保人和审计师通常接受以下内容：

• 一份已签署的支持协议，其中明确列出了具体组件及其版本
• 该版本 CVE 修复措施的、附有日期且有据可查的记录
• 一份由供应商出具的证明函，确认该支持服务的范围和频率

换句话说，上述合规性和保险风险并不能仅通过在11月10日前完成迁移来解决。真正的解决之道在于，无论您当前运行的是什么系统、无论您的迁移时间表如何，都要确保拥有受支持的补丁更新渠道。真正需要抉择的是：是在一个切合实际的时间表内完成迁移，还是在此期间将这一过渡期转化为一份有据可查、可审计的支持协议。

‍

您切实可行的选择

迁移至.NET 10、桥接并延长支持期限，或两者兼而有之。

目前，所有在生产环境中运行.NET 8或.NET 9的组织，无论是否已明确做出选择，都在这两条路径之间进行抉择。大多数企业最终会两者兼顾：将实际可迁移的应用程序进行迁移，并对无法迁移的应用程序进行过渡处理。

方案 A：迁移至.NET 10

.NET 10 是当前的 LTS 版本，也是仍在使用.NET 8 或.NET 9 的所有系统的预期长期目标版本。微软自身的发布说明中提到了 JIT 和运行时性能的提升、扩展的后量子密码学支持、所有主要平台上的现代 TLS 1.3 支持、控制台应用无需 Dockerfile 即可原生创建容器镜像的能力，以及 Entity Framework Core 10 的更新（包括向量搜索和原生 JSON 支持）。 仅凭这些功能，无论是否临近截止日期，此次升级都值得进行。企业应用程序的升级通常比团队最初预估的时间更长，特别是当涉及传递性依赖、第三方库兼容性以及回归测试时。如果迁移在您的合规时间表内可行，这是正确的首选路径。如果不可行，方案 B 提供了替代方案。

路径 B：通过Never-Ending Support (NES) 进行桥接，用于.NET

.NET 版 NES是一款安全、可直接替换已不再受支持的.NET 6、8 或 9 运行时的解决方案。无需修改代码。它恢复了审计员和承保商所关注的受支持补丁流，同时让您能够按照自己掌控的时间表进行迁移，而非受微软既定日程的限制。

• 可直接了解.NET 的安全流程。HeroDevs是.NET 基金会的企业赞助商，并与微软、Red Hat、IBM和Canonical共同参与.NET 安全小组的工作，该小组负责协调披露前的补丁发布以及.NET 的同步发布。成员会在公开披露前约一周收到源代码补丁，因此.NET 构建版本的NES会与微软的补丁在同一个“补丁星期二”发布。
• 已在该任务中证明了其能力。 .NET 的NES已针对九个.NET 6版本中的62个CVE发布了修复程序，其中56个是在微软停止为.NET 6提供补丁后披露的。
• 无需更换平台。无论在 Windows 还是 Linux 上，运行时行为和部署模式均保持不变。唯一的变化是，补丁会持续发布。
• 您的扫描器可以识别的 OpenVEX 声明。HeroDevs 会为.NET 发布的版本提供包含 NES 的 OpenVEX 声明，因此扫描器会报告该构建修复了哪些 CVE 以及哪些 CVE 不适用，而不是针对已停止支持的运行时列出一长串开放式的发现项。
• 得益于持续的生态系统投资。HeroDevs 设立的 2000 万美元“开源可持续发展基金”为整个开源生态系统中的维护者提供支持，其中包括.NET 。

‍

将此转化为计划

通往11月10日的切实可行路径。

处理得当的团队不会坐等针对整个应用组合做出单一的“迁移还是过渡”决策。它们会按照短暂且具体的时间表，逐个应用程序进行分类处理。无论开始时剩余的时间有多少，以下这种结构都是可行的。

第一步：盘点（第1–2周）

• 列出运行在.NET 8或.NET 9上的所有生产应用程序，包括内部工具和供应商提供的系统
• 标记哪些数据涉及受监管数据（PHI、持卡人数据、PII），或位于 SOC 2/ISO 27001 审计边界之内
• 请注意，哪些产品已启动并正在实施向.NET 10的迁移路径，且该路径有专人负责

第 2 步：根据具体申请情况决定（第 3–4 周）

• 如果.NET 10兼容性工作的范围、资源配置已确定，且在截止日期前确实能够完成，则进行迁移
• 如果迁移时间表延长至11月10日之后，或者该应用程序属于计划退役而非重写的情况，或者需要在迁移工作并行进行的同时立即锁定合规覆盖范围，则应与NES建立过渡机制。

第3步：执行并记录（截至11月10日）

• 对于迁移候选项目：锁定范围、指定负责人，并像处理其他任何以合规为导向的项目一样，按截止日期推进工作
• 致过渡期候选机构：请务必在11月10日之前（而非之后）提交经签名的支持协议和CVE整改记录。这是您下次审计或政策续期时将被要求提供的证明文件。
• 简要向合规、安全部门以及（如适用）您的网络保险经纪人说明每项申请的计划，而不仅仅是那些已经迁移的申请。

第 4 步：11 月 10 日之后

• 请确认所有剩余的.NET 8/9应用程序均已迁移，或已签订有效的支持协议。除此之外，没有其他情况能让审计员满意。
• 应按照桥接方案原本设定的时间表，继续推进桥接应用程序的迁移工作，而不是让“受支持”成为永久的解决方案。

‍

HeroDevs 的定位

如果任何申请无法赶在截止日期前提交，这就是“.NET ”的NES功能派上用场的时候了。

在与我们沟通之前，您无需将这一切都完全理清。大多数对话都是从一个或几个应用程序开始的：要么是那些显然无法按时完成迁移的应用程序，要么是需要在下次审计或政策续签之前（以较早发生者为准）签署支持协议的应用程序。

就 NES 相关事宜与 HeroDevs 联系.NET

适用于.NET 6、8 和 9 的安全、即插即用型补丁。无需修改代码，无需更换平台，且由一支能够直接了解.NET 安全小组披露流程的团队开发。

‍

获取定制报价

‍

来源与方法

本指南仅供一般参考之用，不构成法律或合规建议。受 PCI DSS、HIPAA、SOC 2、ISO 27001 或其他监管框架约束的组织，在参考本指南之前，应先与本组织的合规、法律和审计团队确认具体义务，包括当前要求的详细内容及生效日期。

• 微软，《宣布推出.NET 10》、《.NET 8和.NET 9将于2026年11月10日结束支持》、《.NET STS版本的支持期限为24个月》（2025年9月16日）以及《宣布推出.NET 安全组》（2025年10月14日），.NET 博客。
• Coalition, Inc.《2023年网络索赔报告》，据Businesswire独立报道（2023年5月）：研究发现，存在未解决关键漏洞的组织遭遇网络索赔的可能性高出33%；而使用已停止维护的软件则会使发生安全事件的概率增加三倍。
• 美国卫生与公众服务部，《健康保险流通与责任法案》（HIPAA）安全规则，45 CFR §164.308(a)(1)(ii)(A)和(B)。
• ISO/IEC 27001:2022，附录A，控制措施8.8（技术漏洞管理）。
• CISA 已知被利用漏洞（KEV）目录；FIRST.org 漏洞利用预测评分系统（EPSS）。
• HeroDevs，《HeroDevs加入.NET 基金会，致力于保障和促进开源生态系统的安全与发展》以及.NET 基金会赞助商聚焦（dotnetfoundation.org）：2000万美元开源可持续发展基金以及.NET 安全小组的参与。
• HeroDevsNES for.NET 6.0.x 版本更新日志：在 6.0.38 版（2025 年 6 月 4 日）至 6.0.46 版（2026 年 9 月 9 日）期间共修复了 62 个 CVE，其中 56 个是在.NET 6 停止支持后披露的。
• HeroDevs，《关于 ASP.NET Core 中评分达 9.9 分的 CVE-2025-55315 的常见问题解答》（2025 年 11 月 5 日）。

‍