ShinyHunters的PeopleSoft零日漏洞，实为三个串联缺陷

如果你在六月修补了CVE-2026-35273就把它抛在脑后，那么本周值得问的一个简单问题是：究竟修补了什么？据向Oracle报告该漏洞的研究人员称，ShinyHunters作为零日漏洞利用了数月之久的这个严重PeopleSoft缺陷，并非一个漏洞，而是跨两个独立组件串联起来的三个漏洞。Oracle用同一个编号修复了全部三个。单一编号的补丁，是否足以让你验证防护覆盖，正是这则新闻令人不安之处。

简短的回答是：如果你应用了Oracle的带外修复补丁，那么三个漏洞都已堵上，因为一个补丁覆盖了全部。但编号本身并不能说明这一点，也无法告诉你在打补丁之前是否已有人侵入。关于第二点，证据并不令人安心。Mandiant的指引假定入侵会在打补丁后持续存在。我的看法也是如此。

时间线：零日漏洞持续两周，却被低估了四个月

把日期排列出来，事件的轮廓就更清晰了。从实际意义上说，第0天是5月27日，Mandiant和Google威胁情报小组称，他们追踪的组织UNC6240（即ShinyHunters更为人知的名称）开始利用该漏洞，主要针对大学。这一活动一直持续到6月9日。6月10日，Oracle发布了带外安全公告，附带CVE-2026-35273，这是PeopleSoft Enterprise PeopleTools 8.61和8.62版本中的一个CVSS 9.8分、无需身份验证、可经网络利用的远程代码执行漏洞。在此日期之前，它毫无疑问都是零日漏洞。

该漏洞被列入CISA的已知被利用漏洞目录（KEV），这是理所应当的。六月初，ShinyHunters曾向The Register表示，它已通过该漏洞入侵了100多个机构。随后在九月——距离补丁发布约三个月后——Mandiant记录了第二波规模更大的攻击。目标已远超教育行业，扩展至科技、IT服务、医疗、农业、交通和政府部门，全球数十个系统被植入Web Shell。已修补的漏洞加上不断增长的受害者数量，通常意味着两种情况之一：修补迟缓，或攻击者保留了早前获得的访问权限。在这里，两者似乎都有。

本周，零日漏洞计划（ZDI）的Bobby Gould发布了一份剖析报告，彻底改变了对整起事件的理解，The Hacker News对此作了报道。ZDI团队——Gould与TrendAI研究人员Minh Giang和Lucas Miller——报告了跨两个PeopleSoft组件的三个不同漏洞。Oracle在六月用同一个CVE编号修复了它们。ZDI表示正与Oracle合作为每个漏洞分配独立编号；截至本周，CVE-2026-35273仍是官方记录中唯一的编号。

分步解析：利用链究竟如何运作

有两个组件至关重要，它们都作为独立的Web应用运行。集成网关（PSIGW）负责与外部系统的消息传递。环境管理中心（PSEMHUB）是一个内部管理界面，本应只响应受信任的主机。这条利用链的平淡之处，恰恰是最严重的利用链通常的样子——没有什么奇特的原语，只是一个本不该发布的信任决策。

1. 第一步——PSIGW中的SSRF。攻击者向网关的监听连接器发送请求，同时控制目标地址和转发给它的完整载荷。ZDI称，处理程序并不检查目标是否合法。单看此点影响有限，但它能触及的范围使其变得重要。
2. 第二步——回环信任绕过。PSEMHUB使用名为allowedhosts.properties的文件判断信任对象。该文件默认已将127.0.0.1列入其中。把SSRF指向回环地址，伪造的请求便会看起来像是来自机器本身。信任检查通过，Oracle原本意图隔离的内部界面就此可从互联网访问。
3. 第三步——两种方式实现代码执行。方案A：滥用PSEMHUB中用于写入日志条目的命令。调用者可控制文件内容及磁盘上的确切路径，因此可将Web Shell写入应用目录，并以PeopleSoft服务账户身份执行。方案B：投放一个恶意XML文件，PSEMHUB会在下次服务启动时使用Java的XMLDecoder解析它——无需植入任何Shell即可执行代码。第二种路径留给标准检测的痕迹明显更少。

注意这里没有什么。在攻击发生的环节，这条利用链并不需要新的漏洞利用开发。通过SSRF进入一个信任回环地址的管理界面，是事件响应人员多年来一直在撰文记录的模式。ZDI指出了核心的设计决策：默认信任回环地址，一旦存在任何SSRF，信任检查便形同虚设。如果你的补偿性控制是假定PSEMHUB只能从本地访问的网络规则，那么这一假设在第二步就已失效。

那条未能发挥作用的WAF规则

九月的攻击浪潮中有一个细节，让所有把边界过滤当作缓解措施的团队都应感到恼火。Mandiant发现，ShinyHunters通过对一个字符进行URL编码来规避针对/PSEMHUB/路径的WAF规则——改为请求/%50SEMHUB/。许多WAF规则按纯文本匹配路径，而PeopleSoft服务器会解码该路径并提供页面。仅一个字符，便是纸面上的规则与暴露在互联网上的管理界面之间的差距。

Mandiant明确表示，基于路径的WAF拦截不能替代补丁。我还要更进一步：如果你关于此问题的唯一监测手段是匹配字面路径的WAF规则，那么即便攻击已经成功，你的日志也可能什么都没显示。这一问题本可在何时被发现？在网关层，如果记录并告警出站请求的目标——来自连接器、指向127.0.0.1的SSRF并非正常流量；在文件系统层，应用目录中出现新文件时；在服务重启时，XMLDecoder运行了不该运行的内容。每个阶段都有检测机会，而每一个都需要审视主机本身，而不仅仅是边界。

一个CVE掩盖了什么，补丁又没有修复什么

单一编号的补丁能否让防御者获得足够信息以验证其已被覆盖？只能部分做到。Oracle六月的修复解决了全部三个问题，因此已完全打补丁的系统确实切断了这条利用链——这一点由公告的存在以及ZDI对其所封堵内容的分析可以证实。但已证实的仅止于此。未知的是：应用补丁能否移除攻击者已经建立的访问权限。Oracle的公告并未涉及这一点。Mandiant的指引——排查Web Shell、将任何存在Shell的主机视为已失陷、保全证据、轮换PeopleSoft层可访问的所有凭证——正是基于这一假设：补丁并不能移除。这一假设是正确的。补丁能关上门，却无法驱逐已经身处其中的人，而ShinyHunters的商业模式恰恰是潜伏其中：窃取数据，然后索要赎金。

此次披露还存在一个更宽泛的验证难题。三个漏洞，两个组件，一个CVE。扫描器检测CVE-2026-35273的覆盖情况，只能告诉你补丁已经应用，却无法说明它修复了三个弱点中的哪一个，也无法说明你的allowedhosts.properties是否仍然信任回环地址，或你的网关是否仍会转发任意载荷。若为每个漏洞分配独立CVE（ZDI正与Oracle协调此事），至少能让厂商和安全团队把修复、检测和缓解措施对应到具体弱点上，而不是笼统地归于单一编号。在此之前，声称已修补35273，更多是一种意图表态，而非对安全态势的验证。如果这种模式让你似曾相识——攻击者在数月间悄然串联认证绕过，而防御者却信赖单一修复——那么Qilin与Inc勒索软件团伙的PAN-OS攻击行动便是同样的逻辑。

本周的工作

这里的修复和响应指引来自Oracle和Mandiant，而非ZDI；ZDI的分析只涵盖漏洞本身。按优先级排序：应用CVE-2026-35273的带外修复补丁，并保持在受支持的PeopleTools版本上。若确实无法打补丁，Oracle的公告建议：在多服务器部署中禁用环境管理中心服务，在单服务器部署中移除PSEMHUB应用——限制这些管理端点不会影响正常用户会话。然后，对于在五月下旬至修复之间未修补且可从互联网访问的任何实例，将其视为潜在入侵：对主机进行镜像或保全，搜索应用目录中的Web Shell，并轮换PeopleSoft层可触及的所有凭证。同时准备应对勒索邮件，这正是该团伙变现的方式。

这一教训并非仅仅在于Oracle把三个漏洞塞进了同一个CVE，尽管确实如此。真正的问题在于，这条利用链之所以能够成功，只是因为一个没人质疑的默认设置——受信任主机列表中的回环地址——而叠加在这一默认设置之上的每一项补偿性控制，从防火墙假设到WAF路径规则，都以同样悄无声息的方式失效。请调取你的网关日志。如果PSIGW曾向127.0.0.1转发过任何请求，那么你已经得到答案：修补究竟是这起事件的结束，还是仅仅是中途。