ShinyHunters has returned to Oracle PeopleSoft with a one-character change that slips past literal-path web application firewall rules. Mandiant and Google Threat Intelligence Group report renewed exploitation of CVE-2026-35273 by UNC6240 and web shells on dozens of systems worldwide, across higher education, technology, IT services, healthcare, agriculture, transportation and government. PeopleSoft operators who blocked the Environment Management Hub path at the edge but left PeopleTools unpatched have a live entry point.
Oracle lists PeopleTools 8.61 and 8.62 as affected: an unauthenticated attacker with HTTP access can take over the product through its Updates Environment Management component. Oracle issued an out-of-band security alert on June 10 after the group exploited the flaw as a zero-day from May 27 through June 9, according to Mandiant. The NVD record includes CISA’s known-exploited designation, added June 12. The new September activity crosses the WAF rule that some teams used while arranging the patch.
One encoded character reaches EMHub
The vulnerable endpoint is the PeopleSoft Environment Management Hub servlet at /PSEMHUB/hub. Mandiant saw the group request /%50SEMHUB/hub: %50 is the URL encoding for P. A filter matching /PSEMHUB/ against the raw request path sees a different string; WebLogic decodes the path and routes it to the same servlet. Mandiant writes, “The current campaign demonstrates that UNC6240 adapted to published defensive guidance, targeting organizations that implemented WAF rules but did not patch the vulnerability.”
The September bypass exploits a path-normalization mismatch at the administrative application already affected by the June PeopleTools flaw. An edge block must match the normalized path, including percent-encoded and mixed-case variants. Mandiant now recommends applying Oracle’s security-alert patch and disabling EMHub in multi-server configurations or removing the PSEMHUB application in single-server configurations. Restrict the EMHub and Integration Broker listening components from public access; ordinary PeopleSoft Internet Architecture user sessions do not require public exposure of those administrative endpoints.
Probes leave different traces
Before exploitation, targeted servers typically received five to 15 POST requests to /%50SEMHUB/hub containing serialized Java objects. Mandiant says an unpatched server can answer with its operating system while writing no file. A matching request warrants investigation even if a file search comes up empty: some validated hosts had no subsequent exploitation in the observed sequence.
Search PeopleSoft Internet Architecture WebLogic access logs for /PSEMHUB/, /%50SEMHUB/ and other normalized equivalents, especially external POST requests to /hub and requests for unexpected .jsp or .jspx files in PSEMHUB or PORTAL. Carry the search across every node behind a load balancer. The group sent bursts of requests behind load balancers, where repeated requests could land on different nodes; inspect every node starting from the first affected server.
Web shells and fileless commands
Mandiant observed two exploitation outcomes from Java deserialization in the servlet. The group created JSP web shells including x.jsp and u.jsp in <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/; it also ran commands with output returned in the HTTP response and no file written. For that second path, inspect process telemetry for cmd.exe, /bin/sh or bash spawned by the WebLogic Java process. A filesystem-only hunt misses it.
On compromised Windows servers, the group used the upload shell to stage and execute Ple64.exe, a trojanized installer that loads the SIDEEYE backdoor. Mandiant observed tunnel.jsp and tunnel.jspx for HTTP tunneling, and unexpected MeshAgent remote-management installations. A quarter of the observed commands across compromised instances ran as root or NT Authority\SYSTEM; others ran as PeopleSoft or WebLogic service accounts with access to configuration files and database connection strings.
Check PSEMHUB.war/ and PORTAL.war/ for unexpected .jsp, .jspx and .exe files, plus the PSEMHUB envmetadata/transactions/ directory for unauthorized content. Mandiant publishes these file hashes for matching: x.jsp (48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494), u.jsp (2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7), tunnel.jsp (419c571ee38b7e7266d130c4b6bbc4dd0ef44d6e5f3bc02cc2cf73b762f07c86), tunnel.jspx (ba14419beb2ec0bb94cab6298c14d7fb3e1d819366fe378290c0c2a4d97f7e07) and Ple64.exe (3ba215692665513abfffd4e815c5c45f2d41e5dcc4283a2a3b740930c5c417c3). Shell hashes can vary with a newline or tunnel key, so inspect the directories as well as hashes.
Patch and verify every node
Apply Oracle’s CVE-2026-35273 security-alert patch to affected PeopleTools installations. Confirm installed patch levels on each PeopleSoft web node against the Oracle alert, and disable or remove EMHub as appropriate. Then test the edge rule against the normalized PSEMHUB path: encoded variants must be blocked before they reach WebLogic, while normal PeopleSoft user sessions continue to work. An edge rule alone leaves the vulnerable servlet on any reachable unpatched node.
For triage, correlate encoded-path access logs with new JSP files and Java-spawned shell processes. Review outbound PeopleSoft-host traffic to the Mandiant-listed attacker infrastructure: 5.199.162[.]157 (scanner and callback), 104.219.234[.]138 (staging and remote management), 162.219.30[.]165 (SIDEEYE on TCP 3333 and 3334) and winmanage-me[.]network (MeshCentral infrastructure). Where these traces indicate compromise, preserve host evidence, examine HR, payroll and student-record database exports and outbound transfers, and rotate credentials the PeopleSoft service account could read, including psappsrv.cfg database strings, Integration Broker secrets and reachable cloud credentials.
Treat each load-balanced node as its own host during the check. A patched first node alongside an exposed second node leaves the same route open; a clean JSP directory alongside Java-spawned shells misses the fileless route. The useful result is an installed patch and restricted EMHub on every node, with access logs and process telemetry reviewed for the period of exposure.