85%的财富500强在用的平台,被一个页面打穿

硅基卫士

AI 安全科普 · 每日更新

点个关注每日见 →

安全这件事，不需要你自己天天研究

交给这里，每天几分钟就够

补丁挡的是PoC 不是漏洞

7月13日，ServiceNow 放出补丁。

7月18日，第一批真实攻击流量出现。

中间隔了五天。补丁装了，PoC 也公开了，很多团队照着 PoC 写了拦截规则，然后就把这件事划掉了。问题是，打进来的那波流量走的不是 PoC 那条路。

同一个入口，同一个最终效果，换了一条利用链，针对 PoC 调的防线全部失效。这就是 CVE-2026-6875 这两天最值得琢磨的地方——它不是又一个"赶紧打补丁"的通告，它是一次关于"打补丁"这个动作本身的现场教学。

大家默认的那个等式

几乎每个安全团队心里都有一个等式：厂商发了补丁 = 漏洞修好了 = 装上就安全。

这个等式在大多数时候是成立的，成立到我们已经不去想它。补丁一到，走变更流程，测试环境验一遍，生产环境推上去，工单关闭。整个链条里没有一个环节会停下来问：我修的到底是那个漏洞，还是那个被公开的利用样本？

两者在纸面上看起来一样。真出事的时候，差得很远。

ServiceNow 这次的洞，官方评级 CVSS 9.5。它藏在 AI 平台（原来叫 Now Platform）的脚本沙箱里。这个平台一年跑一千亿次企业工作流，财富 500 强里 85% 的公司在用它——这个数字不是修辞，是攻击者选目标时会先看的那一栏。一个未认证、不需要钓鱼、不需要任何前置立足点的远程代码执行，配上这个装机量，性质就从"排期打补丁"变成了"今晚就得看一眼"。

一个感谢页，怎么变成执行入口

攻击的起点特别不起眼：一个叫 assessment_thanks.do 的页面。字面意思就是问卷填完之后那个"感谢您的参与"页。

它接受未认证用户直接传入的参数，而这个参数会流进 ServiceNow 的 GlideRecord 查询接口。麻烦在于，这个接口的 addQuery() 调用允许一个 javascript: 前缀——一旦带上这个前缀，平台会先把后面那段 JavaScript 当表达式算出来，再拿结果去做查询。一个查数据的接口，被塞进了一段会被执行的代码。

ServiceNow 不是没设防。它的脚本环境是两层沙箱：外层给脚本接近平台管理员的能力，但和操作系统隔开；内层专门收拾用户传进来的输入，把 eval、new Function、函数声明、大部分 Java 类访问全都堵死。听起来挺严密。

漏洞就活在这两层的缝里。内层沙箱堵住了直接执行，但没堵 gs.include()——这个函数用来加载平台自带的脚本库，而它加载的代码，跑在外层那个宽松环境里。内外两层共享同一个全局作用域。于是攻击者在内层改一个全局对象（比如 Object.clone），外层加载的库代码执行时就会用到这个被改过的对象，一脚踩进陷阱。沙箱没被砸开，是被借道了。

补丁之后，第二条路

到这一步，故事和无数漏洞一样：研究员 Searchlight Cyber 公开了完整技术细节，写清楚了那条 gadget 链——覆盖 Object.clone、设置原型、调用 gs.include 触发执行。ServiceNow 在四月就收到报告，当天就上了云端缓解，七月放出正式补丁。流程堪称教科书。

然后威胁情报公司 Defused 在周末发了一条推文，把教科书翻到了下一页：在野攻击打的是同一个 assessment_thanks.do 入口，但用的是另一条 gadget 链，绕开了所有照着公开 PoC 调的防御。

这条推文的分量，比补丁本身还重。它把一个平时说不清的道理摆到了台面上——

来源：Searchlight Cyber 技术分析 / Defused 威胁情报（2026-07）

Searchlight 公布的是一条能穿过缝隙的路。Defused 确认了第二条。而只要那个 gs.include() 桥还在，任何能在被加载库的执行上下文里调起 Function 构造器的 gadget，都是一条新路。路不止一条，封住一条就换下一条。

修 PoC 和修漏洞，差在哪

这才是这篇文章真正想说的那件事。

针对 PoC 做防御，本质是在识别"攻击长什么样"。你拿到样本，提取特征，写规则拦截这个特征。它对已知样本 100% 有效，对同一个漏洞的下一个变体，0% 有效。

修漏洞，是消除"攻击为什么可能"。ServiceNow 这次真正的修法，不是把那条已知 gadget 链堵上，而是引入了一个叫 Guarded Script 的架构改动：内层沙箱从此只接受单条、简单的表达式，变量声明、控制流、函数声明、多语句脚本，全部拒绝。

为什么这招管用？因为每一条已知的 gadget 链都需要多步操作——覆盖一个全局函数、设一个属性、调一个 include，至少三步。Guarded Script 把"多步"这个前提铲掉了。没有前提，就没有任何 gadget 链能拼出来，不管它是已经公开的那条，还是还没被发现的第 N 条。

修 PoC 和修漏洞的全部区别就在这：一个封路径，一个拆前提。封路径是打地鼠，拆前提是把地鼠洞填了。

把这个对照拿去看你自己团队上一次的应急响应记录——那次你到底做了哪一种？

为什么这件事偏偏现在扎眼

ServiceNow 不是第一次出这种洞。2024 年的 CVE-2024-4879，同样是未认证、同样被 Assetnote 发现，技术细节公开后几天内，超过 105 家机构被打，包括政府、能源和软件公司，被偷的数据挂上了黑产论坛，CISA 把它列进了已知被利用漏洞目录，给联邦机构下了强制修复期限。

剧本几乎一模一样：公开技术细节 → 攻击者几天内改造成批量扫描工具 → 大规模利用。区别是这一次跑得更快——CVE-2026-6875 是 ServiceNow 近年少见的"攻击者跑赢了补丁采纳周期"的案例，前几个洞（CVE-2026-0542、被叫作 BodySnatcher 的 CVE-2025-12420）都是在确认利用之前就修完了，这一个没能。

还有一层让人不舒服的东西：截至攻击流量出现后两天，ServiceNow 的官方通告里仍然写着"尚未发现针对实例的利用"。而它六月那次未认证 API 数据泄露事件，通告是在修复四天后才发的，还得登录客户门户才能看到。打补丁节奏完全跟着厂商通告走，等于一直在用一个带系统性延迟的信号源做决策。

今晚能做的三件事

先说最要紧的：确认补丁真的落到位了。云托管实例是自动更新的，但要核实这次更新没被某个自定义配置回滚掉——"应该自动打了"不等于"打上了"，这是最低限度的核对，不是可选项。自托管的实例得自己对版本号，Brazil、Australia Patch 2、Zurich Patch 7b/9、Yokohama Patch 12 Hot Fix 1b/13 这些是修好的版本，低于对应版本一律算没修。

然后盯住那个入口。assessment_thanks.do 是确认的活跃攻击点，监控它的异常流量，尤其是外部 IP 段和非工作时段的访问。同时翻日志找后利用痕迹——莫名其妙的工作流变更、新建的用户或角色、异常 API 调用、web 服务里冒出来的脚本执行。

最后一件事和这个洞无关，和你的方法论有关：网络层规则可以在补丁到位前减小暴露面，但它减小的是暴露，消除不了漏洞。打补丁不能被网络层签名替代——这次的第二条 gadget 链就是活生生的反例。

升级之后还有个小尾巴：Guarded Script 的单表达式限制可能会打断现有的自定义脚本，记得查一遍不兼容清单，别修好了洞又崩了业务。

补丁装完，先别关工单——问一句：我封的是那条路，还是那个洞？

下一个 ServiceNow 级别的未认证 RCE 不会等你把这次的复盘做完。真正该改的，是"补丁装上就等于安全"这个装在每个人脑子里、平时从不被质疑的等式。

参考资料

· BleepingComputer：Critical ServiceNow code execution flaw now exploited in attacks（2026-07-20） https://www.bleepingcomputer.com/news/security/critical-servicenow-code-execution-flaw-now-exploited-in-attacks/

· The Hacker News：Critical ServiceNow AI Platform Flaw Exploited for Unauthenticated Code Execution（2026-07-20） https://thehackernews.com/2026/07/critical-servicenow-ai-platform-flaw.html

· Help Net Security：ServiceNow pre-auth RCE exploited in the wild (CVE-2026-6875)（2026-07-20） https://www.helpnetsecurity.com/2026/07/20/servicenow-cve-2026-6875-exploited/

· Searchlight Cyber：Smashing the ServiceNow Sandbox — Pre-Authentication RCE https://slcyber.io/research-center/smashing-the-servicenow-sandbox-pre-authentication-rce/

· ServiceNow 官方通告 KB3137947 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3137947