想象一下，你为了测试方便，从官方帮助门户拷贝了一段配置脚本，部署到生产环境后便忘了这件事。几个月后，系统数据被悄然读取、篡改，攻击者所用凭证竟是那段脚本里硬编码的公开密钥。这不是假设——在SAP最新一期安全更新中，一个由示例配置引入的默认凭证漏洞，正以9.1的CVSS评分提醒企业检查自身环境。
SAP 2026年7月安全更新一口气修复了多个严重漏洞，其中最引人关注的是三个评分均突破9分的致命缺陷。安全公司Onapsis在通报中逐条剖析，将这些漏洞的利用条件、临时缓解方案以及长期修复路径摆上了台面。从NetWeaver ABAP应用服务器到Commerce Cloud，这些漏洞覆盖了SAP生态中多个关键组件。
先看被标记为CVE-2026-44747的漏洞，它在通用漏洞评分系统里拿到了9.9分，几乎触顶。该漏洞出现在SAP NetWeaver应用服务器ABAP中，是一个越界写缺陷。攻击者需要先获得身份认证，之后便能利用内存管理中的逻辑错误制造内存破坏，最终导致未授权的数据访问、数据篡改，甚至让整个系统不可用。
Onapsis给出了一个临时缓解措施：通过事务代码SICF，禁用所有带有特定属性的ICF节点。不过这一刀切的做法直接切断了SAP GUI for HTML中打开事务的功能，意味着并非所有客户都能承受这样的操作限制。Onapsis的原话是：“这一缓解措施并不适用于所有客户，我们强烈建议安装相应的补丁ABAP内核版本。”
相比之下，另外两个严重漏洞都以9.1分紧随其后。第一个是CVE-2026-27690，这是一个HTTP请求/响应走私漏洞，作用于非Cloud Foundry环境下的SAP Approuter部署。攻击者甚至不需要任何凭证，只需发送一个精心构造的HTTP请求，就能造成请求与响应的失步，进而暴露其他用户的响应内容，并触发拒绝服务攻击。
第二个9.1分漏洞CVE-2026-44761则直指配置管理中最常见的人为疏忽——默认凭证。该漏洞位于SAP Commerce Cloud中，源于系统保留了一个示例OAuth 2.0客户端，而这个客户端使用的凭证正是SAP帮助门户文档中公开提供的示例配置。美国国家标准与技术研究院国家漏洞数据库的描述明确指出：“如果不做修改，未认证的攻击者就可以利用这些众所周知的凭证获取有效访问令牌，随后调用特定API读取和修改数据。成功利用该漏洞会对机密性和完整性造成高影响，但不对可用性产生影响。”
Onapsis在技术分析中进一步还原了漏洞的产生链条。根源是SAP帮助门户历史上提供过一批示例配置脚本，这些脚本的本意是方便开发与测试，但其中硬编码了广为人知的OAuth 2.0客户端凭证。问题在于，旧版文档并没有明确警告用户不要将这些默认设置导入生产环境。一旦企业执行了示例脚本，并且没有替换其中的硬编码密钥，生产环境中就留下了一个携带公开凭证的客户端。攻击者无需破解任何密码，直接用公开信息换取访问令牌，即可调用相关API读取和篡改系统数据。
也就是说，漏洞的利用存在一个明确的前提条件：企业执行了那套示例脚本，且保留了由此生成的OAuth 2.0客户端，没有替换密钥。相反，如果企业已经删除了该示例客户端，或者已将密钥替换为强密码、唯一值，则完全不受该漏洞的影响。Onapsis据此给出的建议非常直接：审计所有生产环境，确认是否存在受影响的示例OAuth 2.0客户端，一旦发现，立即移除。
从Onapsis披露的细节来看，CVE-2026-44761的技术门槛很低，但危害路径却异常清晰。不需要绕过多重认证，不需要挖掘内存漏洞，仅仅因为测试环境与生产环境的边界模糊，企业就为攻击者敞开了一条直通数据的通道。这种从文档示例演变成生产漏洞的案例，也在提醒使用SAP Commerce Cloud的团队，配置审计必须覆盖那些看似“无害”的官方示例。
截至本月安全更新发布，尚无证据表明这些漏洞已被在野利用。但考虑到CVE-2026-44761的利用方式完全依赖公开信息，且攻击前不需要任何认证，安全研究人员普遍认为留给企业修复的窗口不会太久。SAP的补丁已就绪，对于CVE-2026-44747，安装补丁ABAP内核版本是首选；对于CVE-2026-27690和CVE-2026-44761，也需要根据对应组件尽快部署更新。与此同时，结合Onapsis的建议，对SAP Commerce Cloud生产环境进行配置级
热门跟贴