ServiceNow API漏洞致客户数据遭未授权访问：已遭野外利用

导语：企业 IT 服务管理平台 ServiceNow 近日确认，攻击者利用其一个未加认证防护的 REST API 端点，直接查询客户实例数据库中的敏感表数据。目前已知攻击活动发生在 6 月 2 日至 3 日，但安全研究人员认为攻击者已在野外部署约两个月。这是 ServiceNow 近八个月来第三起高危漏洞事件，也是首次被证实已遭实际利用的一次。

一、事件概述

1.1 漏洞详情

根据 ServiceNow 官方支持公告（KB3067321）以及多家安全研究机构的分析此次事件源于一个 Scripted REST API 端点 /api/now/related_list_edit/create 被错误配置。该端点在部署时将 requires_authentication 参数设为 false，导致任何未经身份验证的请求都能直接访问客户实例中的数据库表。

受影响的客户范围主要包括：使用澳大利亚平台版本（Australia platform release）的托管客户，以及实施了特定配置更改的旧版本用户。ServiceNow 已于 2026 年 6 月 5 日对托管客户实例应用了安全更新，将该参数调整为 true，从而强制执行认证要求。

值得注意的是，由于攻击请求以访客用户（Guest user）身份执行，相关活动在事务日志中可能被误认为正常访问，增加了事件排查的复杂性。

1.2 攻击时间线

安全研究人员发现，异常活动最早可追溯至约两个月前，主要攻击窗口集中在 2026 年 6 月 2 日至 3 日。攻击者使用 IP 地址 51.159.98.241 对受影响客户发起定向查询。社区报告显示，每个受影响租户平均遭遇约五次查询，部分组织可能面临更多次攻击。

目前 ServiceNow 尚未为此漏洞分配正式 CVE 编号，仍在评估是否公开披露。

二、影响范围与数据类型

2.1 受影响数据

ServiceNow 作为企业核心 IT 服务管理（ITSM）平台，通常存储以下敏感数据：

IT 支持工单：包含故障描述、解决步骤、内部讨论
员工记录：部分实例中存有员工个人信息和组织架构数据
内部知识库文章：技术文档和操作手册
安全事件报告：漏洞和入侵相关记录
工作流配置：业务审批流程和自动化规则
资产清单：IT 设备、应用系统和配置信息

特别值得关注的是，IT 支持工单中经常包含凭证信息、API 密钥、内部文档和故障排查过程中共享的认证凭据，这些数据一旦泄露可能被攻击者用于横向移动或权限提升。

2.2 国内关联风险

ServiceNow 在国内被大量大中型企业、外资企业及 IT 服务管理平台广泛采用此次数据泄露事件可能直接波及国内企业的 IT 运维数据、员工信息和内部流程。尤其是使用托管云版本的客户，需立即确认是否收到 ServiceNow 官方支持通知。

三、漏洞根因分析

3.1 技术层面

此次漏洞的核心问题在于 ServiceNow 平台的一个 Scripted REST Resource 被错误地配置为无需认证。根据社区报告，该端点在初始部署时将 requires_authentication=false，允许任何请求在无需有效会话、认证令牌或凭证的情况下被处理。

这意味着攻击者只需构造特定的 API 请求，即可绕过所有访问控制，直接查询后端数据库表。从安全架构角度看，这违反了”纵深防御”的基本原则——单一认证环节的缺失直接导致整体防护体系的失效。

3.2 三个月内第三起高危漏洞

这已是 ServiceNow 近八个月内披露的第三起高危安全漏洞：

CVE-2025-12420（2025 年 10 月 30 日修复）：涉及平台 AI 增强功能中的权限提升和模拟问题。

CVE-2026-0542（2026 年 1 月至 2 月间修复）：涉及远程代码执行威胁。

与前两次不同的是，此前两起漏洞均在确认被利用之前就已修复，而此次漏洞已确认遭到实际攻击。

四、检测与响应建议

4.1 立即行动

使用 ServiceNow 托管版本的客户无需手动应用补丁，ServiceNow 已自动完成修复。但以下步骤仍需立即执行：

确认是否受影响：登录 ServiceNow 支持门户，查看是否存在相关支持案例通知。ServiceNow 已主动向受影响客户发送通知。

审查访问日志：检查 2026 年 6 月初的实例访问日志，重点关注来自非预期 IP 地址的 API 调用，尤其是以 Guest 用户身份执行的查询请求。可重点检索以下特征：

端点：/api/now/related_list_edit/create
来源IP：51.159.98.241
时间范围：2026年6月2日至3日
用户：Guest

排查敏感数据泄露：确认工单系统中是否存在包含凭证、API 密钥或其他敏感信息的内容，并评估其暴露风险。

4.2 自托管客户注意事项

对于使用自托管（On-Premises）部署的企业，ServiceNow 尚未公开确认是否受到影响或发布专门补丁。建议管理员手动检查所有 Scripted REST API 资源，确认 requires_authentication 参数配置为 true，而非假设自动保护已生效。

4.3 主动防御建议

从长远来看，安全团队应以此事件为契机，对 ServiceNow 实例进行全面安全审计：

API 资源审计：审查所有 Scripted REST API 资源，特别关注旧版本或遗留资源，确认其认证配置正确。

最小权限原则：确保 API 访问遵循最小权限原则，避免过度开放数据访问面。

日志监控：建立针对异常 API 访问的监控规则，对高频次、跨表查询等可疑行为设置告警。

凭证轮换：考虑到工单中可能泄露凭证，建议对相关系统的访问凭证进行预防性轮换。

五、总结

此次 ServiceNow API 漏洞事件再次凸显了企业 SaaS 平台面临的安全风险——单一配置错误即可导致大量客户的敏感数据暴露。对于国内大量使用 ServiceNow 的企业而言，这不仅是一次技术事件，更是对供应链安全和第三方服务依赖关系的警示。

从防御者视角来看，此次事件有几个关键教训：一是 SaaS 平台的认证机制不能被视为理所当然，需主动验证；二是日志中的”正常”访问记录未必可信，Guest 用户身份可能是攻击者的伪装；三是响应速度至关重要，ServiceNow 从发现异常到发布修复用了约三天，但攻击者已在野外部署约两个月。

文章版权归作者所有，未经允许请勿转载。

THE END

ServiceNow 确认 API 漏洞致客户数据遭未授权访问：已遭野外利用