ServiceNow AI 平台：沙箱逃逸导致无需认证的代码执行

这是什么？

2026 年 7 月 13 日，ServiceNow 就其 AI 平台中的一个严重漏洞发布了安全公告（KB3137947）。该平台层负责运行由 AI 辅助的功能，以及这些功能在 ServiceNow 环境中生成或执行的代码。此漏洞被描述为沙箱逃逸：在特定条件下，攻击者可以突破平台所依赖的受限执行环境，直接在实例上执行代码。其严重之处在于，据 ServiceNow 所述，利用该漏洞无需认证，且同时影响由 ServiceNow 托管的部署与自托管部署。

ServiceNow 表示已修补其托管实例，并向自托管客户与合作伙伴提供了补丁；截至公告发布之日，尚未发现在野利用。该公司刻意在公告中省略技术细节，以便在可靠利用代码出现之前给客户留出打补丁的时间——这是针对尚未被利用的严重漏洞的常见负责任披露做法。

工作原理

ServiceNow 并未公布底层技术成因，因此以下描述的是漏洞类别，而非可用的利用代码。AI 平台通常会在沙箱内执行不受信任或由模型生成的内容——表达式、脚本、工具调用——沙箱旨在限制这些代码能够触及的范围。沙箱逃逸是指任何允许边界内代码突破边界的缺陷：API 接口上缺失的限制、可从沙箱访问且暴露特权功能的对象，或以超出预期权限执行攻击者可控输入的解析或求值路径。

关键的结构性要点在于两个属性的组合。其一，易受攻击的接口无需凭据即可访问，这就把”经过认证的用户可能作恶”变成了”任何能够通过网络访问该实例的人都可作恶”。其二，逃逸成功后，攻击者将进入平台自身的执行上下文——在一个用于 IT 服务管理、工作流自动化与安全运营的系统上，攻击者可能扰乱业务流程、读取或篡改记录，或借助该实例可达的其他系统进行横向移动。

为何重要

企业会将大量敏感流程放在 ServiceNow 上运行，而实例往往因设计而暴露于较大的网络范围。针对此类平台的无需认证代码执行原语已接近最坏情况：无需钓鱼，无需窃取令牌，仅凭对未打补丁实例的网络访问即可。未观察到利用只是微弱的安慰，因为严重的无需认证漏洞一经公开披露，往往会加速逆向工程——从”补丁发布”到”利用代码出现”之间的窗口通常很短。

从更宏观的角度看，随着 AI 功能在企业平台中普及，这一模式值得深刻理解：每一项新的”让 AI 执行此操作”的能力都会附带一个新的执行沙箱，而这个沙箱如今已成为攻击面的一部分。功能的安全性取决于包裹它的边界的安全性，而与它们所嫁接的成熟平台相比，这些边界都很新、很复杂，且远未经过充分检验。

防御

具体的当务之急是打补丁，但持久的经验在于架构层面。

• 按版本系列应用补丁。 ServiceNow 已在其受支持的版本线上修复该漏洞——对于自托管实例，请安装对应版本系列的补丁（公告列出了已修复版本，包括近期的 Zurich 与 Yokohama 补丁级别），而不要假定托管端的修复会覆盖你。
• 确认托管或自托管状态。 托管客户应核实更新已应用；自托管管理员掌握着自己的打补丁节奏，即便没有活动迹象也应视其为紧急。
• 收敛网络暴露面。 当实例并非广泛可达时，无需认证的漏洞危险性会大幅降低。将 ServiceNow 置于网络层限制之后（VPN、IP 白名单、WAF），使”网络访问”不等同于”互联网”。
• 将 AI 执行沙箱视为信任边界，而非便利设施。 任何执行模型生成或用户提供代码的平台，都应假定沙箱终将被突破：最小化其可触及的范围、默认拒绝出站网络，并将平台自身的凭据限制为最小权限。
• 监控补丁后的滥用行为。 关注管理活动、意外的集成、异常的工作流或记录变更，以及反常的 API 行为——这些正是逃逸成功会产生的信号，即便入口点现已被封堵。

Status

项目	内容
产品	ServiceNow AI Platform（托管与自托管）
性质	沙箱逃逸 → 无需认证的远程代码执行
披露	2026 年 7 月 13 日（公告 KB3137947）
参考编号	CVE-2026-6875
修复版本	Brazil EA/GA；Australia Patch 2；Zurich Patch 7b/9；Yokohama Patch 12 HF1b/Patch 13
在野利用	截至披露之日未知
是否需要认证	否

关键日期：2026 年 7 月 13 日——ServiceNow 公告与补丁；2026 年 7 月 14 日——媒体报道。ServiceNow 未公布根因细节，符合利用发生前的负责任披露做法。