SAP 2026 年 9 月内核漏洞要求立即开展资产盘点与补丁响应

SAP 2026 年 9 月安全补丁日包含两项需要运行 SAP 环境的组织立即关注的严重漏洞。其中一项是 SAP 内核中的最高严重性漏洞，存在于 Extended Passport 处理流程中，编号为 CVE-2026-44756，Onapsis Research Labs 将其命名为 OVERPASS。另一项漏洞编号为 CVE-2026-58240，影响 SAP NetWeaver Message Server，被称为 S4GET。受影响系统中的这两项漏洞都可以在无需身份验证的情况下从远程触达。

关键并不在于每一套 SAP 安装都已经遭到入侵。真正需要重视的是，这些漏洞位于被多条通信路径共同使用的基础设施中，其中有些路径可能因为主业务应用没有直接暴露在公共互联网而被管理员误认为受到保护。因此，第一步不是等待一份轰动性的入侵报告，而是确认环境中有哪些内核和 Message Server 组件、它们能否从不可信网络访问，以及供应商修复是否已经真正安装并完成重启。

本文关注的是防御问题：SAP 负责人应如何把一份高严重性安全公告，转化为关于自身环境的可验证证据？

SAP 于 9 月 8 日披露了什么

SAP 通常在每个月的第二个星期二发布安全补丁日公告。2026 年 9 月公告列出了相关安全说明、受影响的产品版本，以及受支持版本的修复内容。本文讨论的两项问题并不是局限于某个可选业务功能的普通应用缺陷，而是涉及 SAP Kernel 与 NetWeaver Message Server。这些组件可能位于多个产品和协议的底层。

CVE-2026-44756 由 SAP Security Note 3747649 处理。其底层问题被描述为 SAP Kernel 处理 Extended Passport 数据时边界校验不足。Extended Passport 是随请求传递的追踪结构。在存在漏洞的实现中，经过构造的异常数据可能造成内存破坏或其他未定义行为。CVE 记录将其描述为一种可通过网络触达、并且会对机密性、完整性和可用性造成较高影响的情况；Onapsis 评估其实际后果可能包括在 SAP 主机上执行操作系统命令。

CVE-2026-58240 由 SAP Security Note 3759472 处理。该漏洞涉及 SAP NetWeaver Message Server 中缺失的身份验证检查，具体组件标识为 BC-CST-MS。Message Server 负责协调 SAP 环境中的应用服务器注册和通信。如果系统把未经授权的组件接受为可信组件，那么原本只为内部集群成员设计的边界，就可能变成进一步扩大入侵范围的通道。

相关技术摘要并非来自欧洲联盟网络与信息安全局。这里的相关机构是 CERT-EU，即负责欧洲联盟各机构、机关、办公室和机构网络安全响应的计算机应急响应团队。CERT-EU 认为这两项漏洞无需身份验证即可远程利用，因此运营层面的风险十分严重，并建议尽快应用两份 SAP 安全说明。

为什么内核问题不只是一个 Web 端点漏洞

OVERPASS 这个名称容易让人以为它只是某个狭窄功能中的缺陷。这种理解并不准确。Extended Passport 处理属于共享的内核功能。Onapsis 表示，存在漏洞的处理流程可以通过不止一种协议和不止一层面向 SAP 的接口触达。报告的路径包括面向互联网的 Web 层、与 SAP GUI 相关的通信，以及 SAP 系统之间的 RFC 连接。

这并不意味着每一种协议在每个部署中都处于暴露状态。但它意味着，仅仅说我们的 SAP Web 界面位于 VPN 之后，并不足以结束调查。同一段内核代码可能存在于以下系统或链路中：反向代理后方的系统、采用远程访问设计的系统、合作伙伴连接、内部集成网段，或者另一套 SAP 系统。正确的问题是：安装了哪些受影响的内核二进制文件，哪些接口会加载它们，以及哪些网络主体能够访问这些接口？

这一差异在分诊时很重要。漏洞可以无需身份验证，但不一定公开暴露在互联网。只要相关服务可达，内部攻击者、已被攻陷的工作站、遭入侵的合作伙伴网络，或者分段不当的管理区域，都可能成为足够的起点。反过来，即便某项服务确实处于隔离状态，仍然需要修补，因为隔离假设会改变，存在漏洞的组件也可能在日后的架构调整中重新被使用。

Onapsis 在其公开公告中有意没有披露漏洞利用细节。这对防御人员是有帮助的：现有信息已经足以确定修复优先级，同时不会让新闻文章变成利用指南。但这也意味着，安全团队不应因为尚未出现公开概念验证代码，就把修复工作推迟。

为什么 S4GET 会改变信任边界的讨论

第二项漏洞的机制不同，但后果相近。NetWeaver Message Server 的设计目标，是协调 SAP 集群中的各个组件。这一设计依赖于系统能够区分合法应用服务器和未经授权的系统。CVE-2026-58240 表明，在受影响版本中，相关身份验证检查并不充分。

根据 CERT-EU 对研究人员发现的摘要，拥有网络访问权限的未认证攻击者可能注册一个未经授权的组件。Onapsis 描述的风险是，攻击者可以把自己伪装成可信节点，使这种信任在集群中传播。如果攻击成功，结果可能包括使用运行 SAP 的操作系统账户执行命令。

这就是网络位置为何重要。Message Server 并不是应用打完补丁后再关闭的普通端口。它属于 SAP 环境的控制平面。如果它可以从用户网络、广泛的服务器网段、合作伙伴网络或互联网访问，那么能够触达它的主体数量就会成为风险计算的一部分。不过，网络过滤只是补偿性控制措施，不能替代供应商修复。它可以在变更准备期间降低暴露面，却无法修复一个失效的信任检查。

Onapsis 还指出了一个棘手的运营限制：存在漏洞的路径可能与 SAP GUI 客户端使用的同一个面向公共的端口相关联。无差别地阻断该端口可能破坏合法登录。这提醒我们，不应在没有应用负责人参与的情况下仓促修改防火墙。有效响应应当把补丁、经过核实的暴露面图，以及范围明确且能够保留必要业务流量的限制措施结合起来。

受影响的范围

受影响版本列表具有技术细节，应当与精确的 SAP 组件资产清单进行比对，而不是把一个产品名称输入扫描器后就据此判断。根据 CERT-EU 的报告，CVE-2026-44756 涉及以下大致版本系列：KRNL64NUC 7.22 和 7.22EXT；KRNL64UC 7.22、7.22EXT、7.53 和 8.04；KERNEL 7.22、7.53、7.54、7.77、7.89、7.93、8.04、9.16、9.18、9.19 和 9.20；以及 WEBDISP 9.16、9.18、9.19 和 9.20。准确的受影响构建版本和修复后构建版本，取决于 SAP 安全说明以及平台组合。

对于 CVE-2026-58240，CERT-EU 报告的受影响系列为 KERNEL 9.16、9.18、9.19 和 9.20。该问题与 NetWeaver Message Server 组件 BC-CST-MS 相关，因此，如果检查没有绑定已安装组件和补丁级别数据，只做通用的 SAP 服务器检查，就会同时产生误报和漏报。

这些列表不能被当作从另一条版本字符串推断安全的依据。SAP 环境经常包含多套系统、为兼容性保留的旧内核二进制文件、补丁级别不同的应用服务器、Web Dispatcher、开发和质量环境，以及系统之间的连接。这些内容未必会出现在与互联网资产相同的清单中。完整响应必须把它们全部纳入考虑。

利用状态：紧急并不等于已经确认遭到入侵

截至 9 月 9 日可以获得的公开证据，尚不能证明这两项漏洞都已在野外大规模遭到利用。Onapsis 表示，在其公告发布时尚未观察到针对 OVERPASS 的主动利用。CERT-EU 建议立即修复，是因为这些漏洞具有较高技术影响且无需身份验证即可远程触达，并不是因为它报告了针对所有 SAP 客户的已确认攻击活动。

这一区别值得保留。严重是一个用于衡量严重程度和确定优先级的信号；正在被主动利用，则是对攻击者行为的观察。二者不能互换。负责任的事件响应流程不应仅凭 CVE 评分就宣布发生入侵，也不应因为尚未记录公开攻击活动，就把漏洞置之不理。

安全团队应持续关注供应商更新、CERT-EU 或各国 CERT 的公告，以及自身遥测数据的变化。本地证据比泛泛的互联网讨论更有价值。以下情况都应提高响应级别：Message Server 出现异常注册、SAP 操作系统账户下产生新进程、异常的管理活动、配置文件或内核文件出现无法解释的变化、异常 RFC 连接，以及 SAP 主机向业务并不使用的目标地址发起出站流量。这些指标单独看都不能证明发生了入侵，但有助于判断是否只需要修补，还是必须启动事件响应。

一套可执行的响应顺序

1. 指定负责人，冻结未经验证的假设

指定一名人员或一个团队，负责协调 SAP Basis 管理、安全运营、网络工程，以及受影响系统的业务负责人。协调人应记录决定和时间戳。这样可以避免企业补丁工作中的常见失误：Basis 团队以为网络团队负责暴露面，网络团队以为应用团队已经打补丁，最后没有人能够证明正在运行的进程已经发生变化。

不要只从通用漏洞扫描开始。应先使用权威的 SAP 系统资产清单，并确认哪些系统确实正在运行。范围应包括生产、灾难恢复、质量保证、开发、沙箱、集成中心、Web Dispatcher，以及迁移或测试期间使用的临时系统。

2. 绘制受影响二进制文件和实际网络路径

对每套系统记录已安装的内核系列、准确补丁级别、操作系统、是否存在 Message Server、是否存在 Web Dispatcher、SAP GUI 或 RFC 暴露情况，以及能够访问相关服务的网络区域。将已安装版本与 SAP Security Note 3747649 和 3759472 中指定的修复版本进行比对。

这张图应回答具体问题：任何相关服务是否绑定在可从外部路由到的地址上？用户工作站能否直接访问？合作伙伴或集成网络能否访问？是否存在经由负载均衡器、反向代理、VPN 集中器、堡垒主机或云安全组的替代路径？生产与非生产系统之间的分段，最近是否经过实际测试？

记录证据，而不仅是结论。一张写着未暴露的工单很薄弱；一张注明接口、防火墙策略、最后验证日期和批准负责人的工单，才能在架构变化时重新检查。

3. 应用供应商修复，随后重启并核验

遵循 SAP 发布的安全说明和组织自身的变更流程。内核更新通常需要协调多个实例、操作系统、高可用安排和维护窗口。把文件复制到服务器上，并不等同于正在运行的进程已经使用修复后的构建版本。

变更完成后，核验每个相关实例的运行版本。检查集群中的所有应用服务器是否都使用预期的内核级别。单独检查 Web Dispatcher 和其他组件。确认故障转移节点、灾难恢复环境或看似处于非活动状态的实例没有被遗漏。如果环境采用自动化部署，应保存部署结果，并与独立的运行时证据进行比对。

成功标准不是补丁作业已完成，而是范围内每个受影响服务都在运行修复后的版本，变更已经记录，并且暴露面评估仍然与实际部署架构相符。

4. 在补丁准备期间使用临时控制措施

如果无法立即升级，应在不把临时措施误认为缺陷修复的前提下降低暴露面。把 SAP 服务的访问限制到最小的授权网络集合。移除不必要的互联网暴露。在业务设计允许的情况下，限制用户网络和合作伙伴网络对管理接口及 Message Server 路径的访问。检查反向代理和负载均衡器规则，不要只修改服务器本地防火墙。

尤其针对 S4GET，要谨慎进行大范围端口阻断。一个破坏 SAP GUI 或集群通信的规则，可能造成可用性事件，却未必能消除所有通往存在漏洞组件的路径。应与 SAP Basis 负责人共同实施变更，针对必要流量进行测试，并保留回滚方案。

如果某套系统无法及时修补，应记录原因、补偿性控制措施、承担风险的人员，以及重新评估的日期。我们以后再修补不是缓解计划。

5. 检查是否存在入侵迹象

即使没有可疑指标，修补仍然必要；如果系统可能已经被访问，仅修补也不够。围绕补丁前的时间范围，检查操作系统进程创建、文件完整性、计划任务、服务定义、SAP 安全审计日志、Message Server 与应用日志、身份验证事件、管理变更，以及网络连接。在日志保留期限届满前，保存相关日志。

检查应包括 SAP 操作系统账户和特权 SAP 用户，但不应止步于此。能够触达主机的攻击者，可能直接操纵操作系统，而不产生明显的 SAP 对话登录。应寻找无法解释的二进制文件、被修改的启动脚本、新建的本地账户、异常出站连接，以及内核文件位置或所有权的变化。

如果证据显示系统可能遭到入侵，应与事件响应团队和 SAP 负责人谨慎隔离。不要在收集理解影响范围所需证据之前就擦除机器，也不要盲目轮换所有凭据。凭据轮换、重建决定和业务连续性行动，都应遵循组织的事件处理流程。

这份公告对不同团队意味着什么

SAP Basis 管理员应把两份安全说明视为一次覆盖整个环境的资产盘点和补丁任务。主要风险是遗漏某个实例、Dispatcher 或恢复环境。Basis 团队还应确认修复后的内核确实正在运行，而不是只相信部署系统显示的状态。

网络团队应核验通往 SAP 服务的真实路径，包括那些不会被普通互联网暴露扫描识别的路径。他们应检查安全组、负载均衡器、VPN 策略、合作伙伴连接，以及用户、服务器、开发和管理网络之间的分段。不了解 SAP 集群和客户端通信的情况下，不应仅凭一行防火墙规则完成变更。

安全运营团队应针对 SAP 主机和操作系统账户周边的可疑活动加强监控。他们应把公告披露时间与本地遥测数据进行比对，并在日志仍可获得时保存证据。漏洞工单和事件工单是两种不同对象；前者不能替代后者。

身份与访问团队如果发现任何利用迹象，应检查 SAP 特权账户和操作系统特权账户。修补软件并不能撤销已经执行的命令，不能挽回可能已被读取的凭据，也不能自动恢复可能被改变的信任关系。

业务负责人应帮助决定哪些系统需要紧急维护，以及哪些通信确实不可缺少。SAP 往往参与财务、制造、物流、薪资、采购或客户运营。响应必须足够迅速，但仓促造成的业务中断也可能带来严重风险。

关闭工单前必须回答的问题

一份经得起审查的关闭记录，应能够回答以下所有问题：

• 检查了哪些 SAP 系统和内核系列？
• 哪些实例、Web Dispatcher 和 Message Server 被纳入范围？
• 更新前后观察到的准确运行版本是什么？
• 哪些系统可以从互联网、用户网络、合作伙伴网络或其他 SAP 系统访问？
• 在相关位置是否应用了 Security Note 3747649 和 3759472？
• 是否核验了所有集群成员、备用系统和灾难恢复系统？
• 使用了哪些临时网络控制措施，由谁批准？
• 检查了哪些日志和遥测数据，以寻找可能的利用活动？
• 是否发现无法解释的进程、注册、管理操作或出站连接？
• 谁接受了剩余风险，何时再次复核？

如果其中任何一个问题的答案是我们不知道，工作就还没有完成。组织仍然可以进入下一项运营步骤，但这种不确定性必须被明确记录。

保持冷静，但不能把它当作普通维护

OVERPASS 和 S4GET 之所以严重，是因为它们在共享 SAP 基础设施中同时具备较高影响和远程、无需身份验证的可达性。它们不是假定每个 SAP 客户都已遭到入侵的理由；截至 9 月 9 日，公开报道也没有证明存在广泛的在野利用。它们真正说明的是，SAP 内核修补不能再被当作一项局部维护工作。

有效的响应需要保持纪律性：盘点真实环境，绘制真实路径，应用 SAP 修复，重启并核验每个受影响组件，在变更期间使用范围经过审慎限定的网络限制措施，并检查遥测数据以寻找此前访问的证据。这样的顺序比恐慌或空泛的安慰更有价值，因为它最终能给出一份有记录的答案：什么处于暴露状态，什么已经修复，以及什么仍需处理。

来源与范围

本文技术事实基于 SAP 2026 年 9 月安全补丁日材料、CERT-EU 关于这两项漏洞的公告、Onapsis Research Labs 的负责任披露简报，以及 CERT-EU 所引用的公开 CVE 记录。针对具体产品的修复，应遵循客户 SAP Support 账户中当前可用的 SAP 安全说明。