本文转自安全牛。
当前，AI智能体已成为软件与SaaS企业产品升级的热门方向，然而在快速落地的背后，攻击面持续扩张，安全风险亦暗流涌动。全球知名企业服务平台ServiceNow近期披露的BodySnatcher(CVE-2025-12420)高危漏洞，正是企业仓促集成AI智能体的典型安全警示——该漏洞可使未授权攻击者直接操控企业AI工具，甚至创建具备管理员权限的后门账户，堪称迄今已发现的最严重AI驱动型安全漏洞之一。
一、BodySnatcher漏洞危害几何？未授权亦可提权并植入后门
该漏洞由安全厂商AppOmni研究人员发现并命名，主要影响ServiceNow的Now Assist AI Agents与Virtual Agent API应用。其核心问题在于权限控制与身份验证逻辑存在双重缺陷，致使无权限攻击者能够以任意用户权限执行智能体工作流。
在默认配置的Now Assist实例中，攻击者借助该漏洞可轻易创建管理员后门账户，实现对企业ServiceNow平台的深度管控。研究人员表示，BodySnatcher漏洞的出现，重新定义了现代SaaS平台中AI智能体相关安全漏洞的典型形态，攻击者可借此远程控制企业AI，将本应简化企业流程的工具异化为攻击武器。
值得关注的是，ServiceNow虽已于10月底完成托管实例的漏洞修复，并为自托管实例用户提供更新包，但相关安全公告与漏洞细节直至上周才正式公开。官方明确指出，用户需将Now Assist AI Agents升级至5.1.18、5.2.19及以上版本，Virtual Agent API升级至3.15.2、4.0.4及以上版本，方可规避基础风险。
然而修复并非一劳永逸。AppOmni指出，本次官方更新仅通过移除Now Assist默认安装的示例AI智能体，阻断了漏洞的验证利用方式，而引发漏洞的危险配置逻辑，仍可能潜藏于企业自定义代码或第三方集成场景中，后续安全风险依然存在。
二、漏洞利用全链路：从身份仿冒到AI提权，三步获取管理员权限
BodySnatcher的完整利用链，围绕ServiceNow Virtual Agent API的设计缺陷展开，从基础身份仿冒到智能体交互执行，每一步均直击平台安全薄弱环节，且利用条件并不严苛。
第一步：借助Auto-Linking轻松仿冒任意用户
Virtual Agent API是ServiceNow用于对接外部聊天界面、机器人的核心接口，其默认采用的Auto-Linking身份验证机制，仅通过邮箱即可完成外部发送者与平台内用户账户的绑定。加之用于验证的静态Message Auth令牌在所有启用实例中通用，攻击者只需获取目标用户邮箱与令牌，即可实现未授权身份仿冒。
此时攻击者虽仅能开展钓鱼类攻击（如冒充可信用户向IT支持人员发送消息），但已为后续权限提升奠定基础。
第二步：绕过认证调用高权限AI智能体
为实现外部AI智能体与内部智能体的交互执行，ServiceNow新增一套需认证的REST API，但该接口本质是原有Virtual Agent API的上层封装，会将请求转换为后者格式并触发AI智能体执行。
这一设计使得新接口的认证要求形同虚设——攻击者可通过未授权的Virtual Agent API直接调用平台内AI智能体，且打破了“智能体需部署至启用Now Assist的渠道方可执行”的常规认知，只要智能体处于激活状态，即可通过特定工作流直接调用。
Now Assist默认搭载的Record Management AI Agent，成为攻击者的关键跳板：该智能体可在平台任意数据表中创建记录，且在所有部署实例中使用相同唯一ID，为攻击者提供了通用的高权限操作入口（目前该智能体已被官方移除）。
第三步：绕过确认机制创建管理员后门
该AI智能体虽处于监督模式，执行任务前会要求请求者确认，但攻击者直接向API发送请求时并不会收到确认提示。研究人员发现，仅需等待数秒后发送“请继续”指令，即可被智能体判定为授权确认。
借助该漏洞，攻击者可仿冒管理员调用Record Management AI Agent，创建由自身控制邮箱的新用户并分配管理员角色，随后通过常规密码重置流程设置新密码，最终获得具备完整管理员权限的后门账户，实现对平台的长期控制。
三、不止ServiceNow：AI智能体的安全风险应如何防范？
BodySnatcher并非个例，而是企业大规模集成AI智能体过程中重功能、轻安全的必然结果。当越来越多企业借助SaaS厂商的AI智能体工具或自研智能体实现流程自动化时，过度授权、身份验证逻辑缺陷等问题，正成为新的安全重灾区。
针对本次漏洞，AppOmni为ServiceNow管理员与安全团队提供了一系列可落地的防护建议，同时也为所有企业集成AI智能体提供了通用安全思路：
1.强化身份验证，完善MFA落地细节：为所有Virtual Agent API调用方启用账户链接多因素认证（MFA），并非简单开启功能，需确保对应脚本包含MFA挑战的执行与验证逻辑，避免防护流于形式。
2.严控自定义智能体，建立审批机制：在AI Control Tower中启用AI管家审批功能，所有自研自定义智能体必须经过安全审查与审批，确保权限与业务需求匹配，杜绝过度授权。
3.定期清理闲置智能体，缩减攻击面：对平台内激活但未实际使用的AI智能体进行定期审查与禁用，避免攻击者利用此类“沉睡智能体”发起同类攻击。
4.排查自定义代码与第三方集成：围绕本次漏洞的核心危险配置，全面检查企业自定义代码与第三方集成方案，及时修复身份验证、权限控制层面的逻辑缺陷。
四、写在最后：AI集成，安全应与功能同步落地
从ServiceNow的BodySnatcher漏洞不难看出，AI技术在企业服务领域的落地，不能只追求速度与功能，而忽视底层安全设计。AI智能体作为可执行高权限操作的自动化工具，本身便是一把双刃剑，若缺乏完善的权限管控、身份验证与监督机制，极易成为攻击者的突破口。
对企业而言，无论是使用第三方SaaS平台的AI功能，还是自研智能体工具，都应将安全评估贯穿集成与开发全流程：明确智能体权限边界，建立严格的身份验证与审批机制，定期开展安全测试，及时修复潜在漏洞。
对SaaS厂商而言，仓促将AI功能推向市场，不仅会给用户带来安全损失，更会损耗自身品牌信任。唯有将安全设计融入AI产品底层架构，在功能迭代的同时同步完善安全防护，才能让AI真正成为企业发展的助力，而非隐患。
在AI快速普及的当下，安全永远是技术落地的前提。本次BodySnatcher漏洞既是一次行业警钟，也为AI智能体安全建设吹响了号角——切勿因仓促集成，让AI成为企业网络安全的阿喀琉斯之踵。
