PeopleSoft编码路径绕过WAF：补丁后仍须查失陷

9月25日，Mandiant与Google威胁情报团队的调查披露，UNC6240（ShinyHunters）再次大规模利用PeopleSoft漏洞CVE-2026-35273：攻击者把“/PSEMHUB/”改写为“/%50SEMHUB/”，绕过部分按原始路径匹配的WAF规则。调查记录了全球数十套系统被部署Web Shell，目标涉及高等教育、科技、IT服务、医疗、农业、运输和政府机构。受到这种绕过威胁的是未安装漏洞修复、主要依靠边界规则拦截入口的部署；调查没有证明已安装的Oracle补丁被绕过。

Oracle在6月10日发布的CVE-2026-35273安全公告将PeopleSoft Enterprise PeopleTools 8.61和8.62列为受影响的受支持版本，并指出漏洞可通过网络在无需认证的情况下利用，成功利用可能导致远程代码执行。运行相关版本的团队需要核对实际对外服务节点是否完成修复；已经安装补丁，也不能据此排除修补前留下的Web Shell、远程访问工具或已被取得的凭据。

9月26日，BleepingComputer的跟进报道同样将这轮绕过指向未安装安全更新、以WAF封堵PSEMHUB入口的系统。这一区别决定了处置顺序：先查补丁和入口暴露，再沿访问日志、主机文件与账户活动追查是否已经失陷。

一个编码字符改变了WAF看到的路径

PSEMHUB是PeopleSoft的Environment Management Hub入口。原本针对“/PSEMHUB/”设置的字面匹配规则，检查的是解码前的请求字符串；攻击请求中的“%50”则是大写字母P的URL编码形式。两种写法在原始请求里不同，解码后却指向同一个PSEMHUB组件。

路径差异出现在请求处理的先后顺序上。假设边界设备先检查原始路径“/%50SEMHUB/hub”，它找不到连续的“/PSEMHUB/”，只拦截后者的规则便可能放行请求。随后WebLogic解码“%50”，请求仍会抵达PSEMHUB的hub servlet；若后端尚未修补，攻击者便能继续尝试利用漏洞。WAF放行只能证明边界规则没有挡住该写法，不能推断应用补丁失效。

这种绕过有明确前提：规则在路径规范化之前进行字面匹配。对解码后的路径实施限制，可以覆盖已知的编码写法；只额外拦截“/%50SEMHUB/”，仍可能漏掉其他百分号编码、大小写或非规范化变体。核查边界配置时，关键是确认规则实际检查请求的哪个阶段，以及代理转发给PeopleSoft服务器的路径最终如何解析。

补丁状态要核到节点，PSEMHUB暴露面要单独核对

Oracle公告列出的版本范围是经确认受影响、仍处于支持范围的PeopleTools版本。退出支持期的旧版本未按同一方式测试，不能因为不在公告表格中就视为安全；Oracle认为较早版本也可能受影响，并建议升级到受支持版本。对已部署修复的环境，应核对每个承接请求的节点，而不只查看变更工单或负载均衡入口的状态。

暴露面核查则回答另一个问题：外部请求能否到达PSEMHUB。需要梳理公网可访问的PeopleSoft Internet Architecture入口、反向代理的转发规则，以及EMHub是否仍承担必要的运维功能。若不再需要该组件，可按部署方式停用EMHub服务或移除PSEMHUB应用；保留服务时，应限制管理入口的外部可达性，并让边界规则针对规范化后的路径生效。

补丁和入口限制可以阻止后续利用，却不会自动清除此前写入的文件或撤销已被取得的账户权限。因此，修复记录与失陷调查应分别形成结论：前者核对当前服务是否仍有漏洞，后者追溯修补生效之前是否发生代码执行。尤其在曾以WAF规则暂时替代补丁的环境中，请求日志的检查范围不能只包含未编码的“/PSEMHUB/”。

从编码请求追查到Web Shell与无文件执行

调查入口应覆盖代理和PIA WebLogic访问日志中的“/PSEMHUB/”、 “/%50SEMHUB/”及其他编码变体，重点查看来自外部的“/hub” POST请求，以及随后对异常JSP或JSPX文件的访问。攻击者曾用包含序列化Java对象的请求探测目标；未修补的服务器可能在响应中返回主机操作系统信息，而不立即写入文件。日志中出现编码路径，意味着入口受到尝试，是否执行成功仍要结合响应、后续请求和主机活动判断。

已观察到的利用方式包括向PSEMHUB.war写入Web Shell，以及直接执行命令并把结果放进HTTP响应。前一种情形可能留下用于执行命令的x.jsp、用于上传文件的u.jsp或相关变体；后一种情形不一定生成JSP文件，却可能出现WebLogic的Java进程启动cmd.exe、/bin/sh或bash。只查新增文件，会漏掉这类无文件执行痕迹。

文件排查可从<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/开始，并覆盖负载均衡后方的所有WebLogic节点。攻击者曾连续发送请求，使不同节点都有机会接收利用请求，因此不能只检查最先出现异常的主机。除x.jsp和u.jsp，还应留意tunnel.jsp、tunnel.jspx和Ple64.exe；这些名称是调查线索，仍需结合文件内容、创建时间、访问记录与进程行为判断。

检查范围还应延伸到PORTAL.war中的非产品文件、PSEMHUB事务目录的异常内容，以及主机上意外出现的MeshAgent。Ple64.exe曾用于在受害Windows主机上投放SIDEEYE后门，隧道文件和远程管理程序则可能在漏洞修复后继续提供访问。若发现Web Shell，应先保全文件与日志，再按失陷主机处理，而不是仅删除可疑文件。

把主机活动与数据访问接成同一条时间线

排查需要区分探测、代码执行、持续访问和可能的数据外传。可将编码路径请求、异常文件创建、Java进程派生系统Shell、远程管理程序启动和外连记录按时间关联，再确定涉及哪些PeopleSoft节点。单独的入口请求不足以判断数据是否被带走；磁盘上没有Web Shell，也不能排除命令直接在主机上执行。

先保存仍可取得的代理、PIA WebLogic和主机日志，标出补丁生效时间、外部请求时间及各节点响应。查看“/hub”请求之后是否出现异常JSP访问、系统Shell进程或新建可执行文件。
沿受影响主机检查异常归档、压缩、传输和持续外连，再对照数据库审计记录，查找人事、薪资或学生记录的异常批量查询与导出。发现大文件或传输进程时，仍需确认其来源、操作者与目的地址。
把Web Shell、隧道程序和远程管理工具的活动与账户登录、数据库连接记录关联，确定攻击者可能使用了哪些权限，以及同一凭据是否也能访问其他节点或服务。

这样排列证据，是为了让处置范围跟随实际入侵链扩展。若只有探测请求，重点是还原请求是否到达后端及修复何时生效；若出现Web Shell或Java进程启动系统Shell，则需进一步检查持久化、凭据使用和数据访问。每一步都应保留对应时间与主机，避免把某个节点的失陷迹象直接推及整个部署。

凭据轮换取决于PeopleSoft服务能读取什么

确认代码执行后，凭据排查应以PeopleSoft和WebLogic服务账户实际可读取的内容为边界。重点包括psappsrv.cfg中的数据库连接信息、Integration Broker凭据，以及Web层能够接触的云服务凭据。轮换前需要查清各凭据被哪些组件使用，同时核对异常登录和连接；只修改面向用户的Web账户密码，无法撤销可能已经取得的数据库或集成权限。

若多个节点共用服务账户，调查还应覆盖同一凭据可登录的其他主机和服务。文件清除、异常进程终止、持久化配置核对与凭据轮换应依据调查结果配套进行。对已经安装补丁的环境，眼下最重要的待查事实是：修补生效前的编码请求止于边界，还是曾在某个节点上留下可持续使用的访问能力。