2026年8月27日，ServiceNow发布月度安全公告，一口气修补了其AI平台（AI Platform，原Now Platform品牌）的四个漏洞——其中三个被直接打出了CVSS 4.0满分10.0：CVE-2026-18885（GraphQL Composite Data API代码注入）、CVE-2026-18886（系统配置镜像上传处理器的访问控制缺陷）、CVE-2026-74820（动态schema ORDER BY子句SQL注入）。三个满分漏洞共享同一组CVSS向量：网络可达、攻击复杂度低、无需任何权限、无需用户交互，对机密性、完整性、可用性的影响全部拉满，且波及与漏洞组件相连的其他系统。翻译成防御者能听懂的话：只要你的ServiceNow实例能被网络访问到，一个连账号都不需要注册的陌生人，理论上就能把它打穿。
这不是ServiceNow今年的第一次红色警报。7月13日，同平台刚披露过预认证沙箱逃逸漏洞CVE-2026-6875（CVSS 9.5），威胁情报公司Defused一度报告观测到其在野利用——虽然随后澄清捕获的载荷与Searchlight Cyber公开的PoC一致，但"预认证RCE"这五个字对企业ITSM中枢的分量，没有任何澄清能减轻。两个月内两轮高危补丁，ServiceNow客户的2026年下半年注定要在升级窗口里度过。
为什么ServiceNow被打穿等于半个企业IT沦陷
要理解这三个满分的分量，得先理解ServiceNow在企业里的生态位。它不是"又一个SaaS工具"——工单流转、变更管理、CMDB资产配置库、服务目录、乃至部分安全编排与自动化，全都跑在同一套平台上。对大量中大型企业来说，ServiceNow就是企业IT运作的"中枢神经系统"，记录着员工信息、资产清单、变更历史、内部流程配置，甚至持有能触达其他系统的集成凭证。
这意味着三类漏洞各自的破坏半径都比表面看起来更大。代码注入（18885）拿到的是平台脚本执行权，可以直接操作实例内数据与自动化流程；访问控制缺陷（18886）实现的是权限提升，普通访问者摇身变成管理员，获得的是对整个平台配置的合法控制力；SQL注入（74820）直通底层MariaDB数据库，实例的全部数据家底敞开任人翻看——而CMDB里躺着的企业资产拓扑，本身就是横向移动的藏宝图。
ServiceNow官方的处置分了两条线：托管实例已直接部署安全更新；合作伙伴与自托管客户拿到了更新包，装不装、什么时候装，自己定。这句话的后半段，正是风险最集中的地方——后文会回到这个话题。
前传：GlideRecord为什么会对javascript:求值
这轮漏洞组的技术源头，要从7月那个CVE-2026-6875说起。Searchlight Cyber（旗下Assetnote团队）7月14日发布的技术复盘，完整展示了这条预认证RCE链的每一环，堪称企业级SaaS漏洞研究的范本。理解了它，才能理解ServiceNow平台架构里那些反复出问题的角落。
ServiceNow不用SQL字符串拼查询——它有自己的查询API GlideRecord，Java后端与JS脚本层共用一套构建器语义。比如gr.addQuery('email', '>', 'walter')表示"email字段按字典序大于walter"。这个设计初衷是安全的：没有文本查询语言，注入理论上无从谈起。但研究者翻官方文档时发现了一个可疑的例子：sla_due<javascript:gs.daysAgoStart(0)——过滤语法里居然允许javascript:前缀。
测试结果令人瞠目：把javascript:'wal' + 'ter'作为查询值传入addQuery，ServiceNow会真的先对这段JS求值，再把结果'walter'当作查询参数。这不是过滤语法专属的彩蛋，而是结构化API层面的行为——查询值会被当作代码执行。而整个代码库里，把未认证用户输入直接传进addQuery的预认证sink俯拾皆是，第一个被发现全版本通用的落点在assessment_thanks.do端点的sysparm_assessable_type参数。
沙箱的三层防线与一条gadget链的诞生
到这里攻击者拿到的只是"受限沙箱内执行JS"——ServiceNow为这类用户可控过滤器准备了额外的脚本沙箱（script sandbox）：主gs对象被替换成功能阉割的GlideSystemSandbox，可实例化的Java类被砍到几乎为零，表访问只读且受严格ACL限制，eval与new Function()被明确禁止。防御设计看起来滴水不漏。
但沙箱有一个特殊通道：gs.include()函数，用于加载ServiceNow预装的脚本库（script includes）。追踪Java层的ASystemInclude.includeScript实现会发现，它为脚本库的求值创建了一个不受沙箱约束的新上下文——否则那些库里的函数定义根本无法加载。于是问题变成：能否通过沙箱内的操作，间接影响这段无沙箱代码的执行内容？
这就是整条链最精妙的部分。脚本库大量使用这样的样板代码：var X = Class.create(); X.prototype = Object.extendsObject(AbstractAjaxProcessor, {...})。而Object.extendsObject的polyfill实现里有一行致命结构：Object.clone(destination.prototype)——一个可被覆盖的函数名（Object.clone，虽然被冻结但可用Object.defineProperty绕过）加一个可被完全控制的参数（AbstractAjaxProcessor.prototype）。攻击者把Object.clone覆写为从脚本库里取出的Function构造器（沙箱内直接访问constructor被禁，但从include取得的函数上取则畅通无阻），把prototype覆写为载荷字符串，再触发一次gs.include()——polyfill会忠实地执行Function(载荷)，无沙箱代码执行就此达成。三个看似无害的机制——include通道、polyfill样板、defineProperty——串成了一条完整的逃逸链。
这条链的影响不止于单实例：Searchlight的报告指出，完整的危害包括ServiceNow实例沦陷以及所有相连的代理服务器——MID Server等连接组件持有的凭证让横向移动顺理成章。
把三个满分漏洞放进这个语境里看
8月的三个10.0，技术上没有公开writeup（Searchlight表示披露时未发布技术细节），但从类型上看，它们与这条历史脉络高度同源：
CVE-2026-18885：GraphQL Composite Data API代码注入。GraphQL是ServiceNow近年力推的现代API层，Composite接口允许客户端在一次请求里编排多个数据操作——这种"把编排能力暴露给客户端"的设计天然放大注入类缺陷的杀伤半径。无需认证即可执行任意代码并读写实例数据，是三个里最典型的"平台执行权拱手相让"。
CVE-2026-18886：系统配置镜像上传处理器的访问控制缺陷。配置镜像（configuration image）是实例间迁移配置的机制，本应严格限定管理员操作——上传处理器缺了授权检查，等于把"直接改写平台配置"的后门开给了匿名访客，权限提升直通管理员。
CVE-2026-74820：经动态schema ORDER BY子句的SQL注入。动态schema是平台灵活性的来源之一，但ORDER BY这类排序子句是SQL注入里最难参数化的位置之一——它天然是"列名/表达式"而非"值"。一个绕过到MariaDB的注入点，意味着UNION读取、时间盲注、乃至（取决于DB权限配置）写操作都成为可能。
同批的CVE-2026-6876（8.7分）是又一个Now平台沙箱逃逸，ServiceNow描述其允许未认证用户执行任意代码——值得注意的是其CVSS向量里PR标为L（低权限），与文字描述的"未认证"存在口径出入，8月公告里这类细节瑕疵不止一处（详见版本矩阵一节），这提示读者：官方公告是必要信息，不是充分信息。
满分是谁打的：一个值得玩味的评分体系问题
这轮披露还牵出一个行业级话题：三个10.0，全是ServiceNow自己打的。ServiceNow是自己产品的CVE编号机构（CNA），而NIST自2026年4月15日起只对进入CISA KEV目录、影响联邦政府软件、或属于行政令14028关键类别的漏洞做NVD丰富化处理。截至8月28日，这四个漏洞一个都没进KEV——于是ServiceNow的自评成了唯一在案的严重度依据，第三方无从独立复核。
厂商作为CNA自评漏洞分数，这在全球CVSS体系里是常态操作，但常态不等于无争议：分数既可能被"手下留情"（毕竟高分直接影响客户恐慌度与合同SLA），也可能被"夸大其词"（满分带来的紧迫感会加速客户打补丁，对厂商不无益处）。这次的三个10.0配合极低的利用门槛描述，更接近后一种。防御者的合理姿势：把厂商评分当作下限参考而非绝对真相，用"攻击面暴露度×业务价值×利用门槛"的三元组自行排级。
一个参照系：7月的CVE-2026-6875（同样未认证、同样RCE）被打9.5，唯一差别是攻击复杂度标为高。而本次三个满分全部标为低攻击复杂度——厂商自己都承认，这批比7月那个"更容易打"。
版本矩阵：四个分支、一长串Hot Fix
受影响版本横跨Xanadu、Yokohama、Zurich、Australia四个发布分支（ServiceNow用城市名命名版本线），修复版本各不相同：
- Xanadu：Patch 11 Hot Fix 7a及之后
- Yokohama：Patch 12 Hot Fix 3b / Patch 13 Hot Fix 4及之后
- Zurich：Patch 7b Hot Fix 3 / Patch 8 Hot Fix 5 / Patch 9 Hot Fix 6 / Patch 10 Hot Fix 2m（m分支）/ Patch 10 Hot Fix 3（标准分支）/ Patch 11 / Patch 12及之后
- Australia：Patch 2 Hot Fix 3 / Patch 3 Hot Fix 2 / Patch 3m / Patch 4 / Patch 5及之后
细心的读者会发现Zurich分支的Patch 10出现了2m与3两个并行的修复点，Australia的Patch 3出现了3 Hot Fix 2与3m——这种分支交错正是大型企业版本管理的噩梦。另一个公告瑕疵：CVE-2026-18886的记录将"Australia Patch 5之前的任何版本"标为unknown（未知），而另外三个CVE把同一版本标为affected（受影响）——同一批公告、同一版本、两种定性。自托管客户的自查动作应当以官方KB3152242为准逐条比对，不放过任何一处unknown。
云托管先修、自托管自理：责任转移时代的补丁困境
这轮事件最值得管理层面正视的，是ServiceNow那句"托管实例已部署更新，自托管客户请联系合作伙伴获取更新包"背后的责任结构。
用官方云服务的企业，这次基本无感——补丁在后台就位了。但自托管实例的客户（往往是定制最深、数据最敏感的那批）面临真实的三难：升级要走变更评审、要验证定制脚本兼容性、要协调业务停机窗口，一套流程走下来按周计；而满分漏洞公开的那一刻起，全球扫描器已经开始嗅探暴露实例——从披露到武器化的窗口期如今常以小时计。7月CVE-2026-6875的剧本已经演过一遍：Defused报告在野利用、ServiceNow回应"未观测到托管实例受影响"——言下之意，风险集中在自托管一侧。这种SaaS行业普遍的"共享责任"模型，在满分漏洞面前显得格外单薄：平台方掌握修复能力但只对自家云负责，自托管方承担全部时间风险却控制不了代码。
检测与排查
- 收敛暴露面：先回答一个问题——你的ServiceNow实例真的需要暴露在公网吗？大量实例本应只对内网或VPN开放，预认证漏洞的第一道也是最便宜的一道防线是网络隔离。互联网资产测绘平台上扫描到的自托管实例数量，往往比企业自己登记的多；
- 审计GraphQL与上传接口的异常访问：对18885，关注GraphQL端点上未认证来源的Composite查询，尤其是包含非业务字段、深嵌套或异常变量的请求；对18886，排查配置镜像上传处理器近期的所有调用记录与来源IP；
- 排查数据库异常查询：74820的SQL注入会体现在MariaDB慢查询日志与审计日志中——关注ORDER BY子句异常、UNION模式、时间盲注特征的查询耗时分布；
- 复查高权限操作：未认证期间（按补丁时间倒推至少30天）出现的权限提升、角色变更、新创建的管理员账户、异常的脚本include调用记录；
- WAF/IDS临时规则：针对GraphQL注入与ORDER BY注入特征建立检测规则，作为升级完成前的过渡性缓解——注意这是缓解不是修复，不可替代补丁。
行动清单
- 自托管立即排期升级：对照KB3152242确认所在分支与Hot Fix版本，走加急变更通道而非月度补丁日节奏。四个分支的版本交错极易看错行，逐条核对，unknown也要当affected处理；
- 确认托管状态与补丁状态：用了ServiceNow云的企业也别只当看客——确认所在区域是否已部署更新，混合部署（云实例+自建MID Server+集成连接器）的组件各自查一遍；
- 轮换集成凭证：打了补丁不等于历史清白。若实例曾暴露且无法完全排除被试探测，轮换平台持有的集成凭证、API密钥与MID Server凭证——参考7月研究，实例沦陷可横向到全部相连代理；
- 把CVSS自评当参考：建立内部评级逻辑——暴露度（是否公网可达）、业务价值（承载哪些核心流程）、利用门槛（认证要求与交互要求）三元组，替代对单一厂商分数的依赖；
- 升级GlideRecord使用规范：企业内定制开发如果存在把用户输入直接传入
addQuery的代码（这是官方文档里就有的模式），立即审计一遍——javascript:前缀行为在平台层修补后，历史定制代码仍可能引入同类风险； - 盯住KEV目录：这批漏洞未进CISA KEV是暂时的。一旦有实际利用证据进入KEV，补丁的优先级排序逻辑要能即时响应——别让"还没进目录"成为拖延的理由。
从Assetnote两年前的三漏洞链，到7月的CVE-2026-6875，再到8月的三个满分——ServiceNow平台的安全叙事已经形成一种模式：灵活性与可定制性带来的巨大攻击面，正在被研究者系统性勘探。对企业而言，选择把业务命脉押在一个平台上，就要接受随之而来的补丁节奏与责任边界。满分漏洞不是ServiceNow一家的问题，它只是把SaaS时代"平台即风险"这个命题，用三个10.0讲得格外清楚。