Skip to main content
Return to Blog TrendAI™ Security
Vulnerabilities and exploits

ShinyHunters Returns to PeopleSoft With a One-Character WAF Bypass

ShinyHunters is once again exploiting a previously patched vulnerability in PeopleSoft, which we analyzed in June 2026.

Threat reportsGeneral marketsExploits & Zero-Days

Key Takeaways

  • SHADOW-AETHER-015 (ShinyHunters, UNC6240) is mass-exploiting CVE-2026-35273 in Oracle PeopleSoft again, three months after Oracle’s emergency patch. Google reported the new wave on Sept. 25.
  • The actor gets past perimeter rules that block /PSEMHUB/ by sending /%50SEMHUB/ instead. %50 decodes to P, and the web application firewall (WAF) sees a path it doesn't recognize, and WebLogic decodes it and routes the request to the vulnerable servlet.
  • The targets are organizations that relied on WAF rules and did not patch. A WAF rule matching the path was a reasonable stopgap in June. It isn’t one now.
  • The attack goes straight to the Oracle Environment Management Hub. Defenders should hunt for requests to the Hub itself, in addition to the gateway indicators in our June analysis. Organizations that applied a path block instead of the patch should patch now and treat the server as possibly compromised until defenders have completed their hunt.

What changed since June

In June 2026, we published an analysis of CVE-2026-35273, a CVSS 9.8 pre-authentication remote code execution flaw in Oracle PeopleSoft PeopleTools 8.61 and 8.62. The bug was reported to Oracle through TrendAI™ Zero Day Initiative™ (ZDI). ShinyHunters had already exploited it as a zero-day from May 27 to June 9, mostly in higher education. Oracle released an out-of-band fix on June 10.

Mandiant’s June advice was to patch and, until then, block outside access to /PSEMHUB/* at the perimeter. Many organizations did that with web application firewall (WAF) rules that match the path as text, and Google’s September report says those are what the actor worked around. It changed one character in its exploit and widened its targeting. Google says the new wave has put web shells on dozens of systems worldwide, in higher education, technology, IT services, healthcare, agriculture, transportation, and government.

How the bypass works

Many WAF and reverse proxy rules compare the raw request path against a string. A request for /%50SEMHUB/hub doesn’t contain the string /PSEMHUB/, so it passes. WebLogic decodes the path before routing, so the request reaches the Oracle Environment Management Hub servlet as if nothing had changed.

Before exploiting a server, the actor sends five to 15 POST requests carrying serialized Java objects to that path. A vulnerable server returns details about the host operating system without writing anything to disk, so the actor can confirm a target quietly. After that, it either runs commands in memory and reads the output from the HTTP response, or drops JSP web shells into the PSEMHUB.war directory. It sent bursts of requests, likely so that every node behind a load balancer got a copy of the web shell.

Two routes to the same flaw

Our June analysis walked through one route to this vulnerability, reported to Oracle through TrendAI™ ZDI: a request to the Integration Gateway that reaches the Oracle Environment Management Hub (the Hub) from inside and runs code when the web tier restarts. (The Hub is a background management service built into Oracle PeopleSoft.) The activity Google describes uses a second route: It sends serialized Java objects straight to the Hub and gets output back immediately. Defenders should hunt for both, because the indicators for one route won’t show the other.

CVE-2026-35273 covers more than one weakness in the same endpoint, and our protections are split the same way (see below). The requests Google describes look like the deserialization weakness used on its own.

The Hub is meant to accept requests only from allowed internal addresses. In the deployments Google describes, it was reachable from outside. One possible explanation is a reverse proxy or load balancer in front of WebLogic: If the Hub sees the proxy as the source of every request, it may treat outside traffic as internal. Whatever the cause, anyone running PeopleSoft should check whether /PSEMHUB/hub answers from outside their network, whatever their block rules say.

What the actor does once inside

Google found that about a quarter of the commands ran as root or NT AUTHORITY\SYSTEM. The rest ran as PeopleSoft or WebLogic service accounts, which can read configuration files and database connection strings. PeopleSoft servers commonly hold HR, payroll, student, and applicant data.

The tooling includes:

  • x.jsp, a web shell that takes hex-encoded commands and builds /bin/sh from character codes to avoid simple string signatures.
  • u.jsp, which uploads files in 150 KB chunks to get around request size limits.
  • SIDEEYE, a C++ backdoor delivered as Ple64.exe, a trojanized Light Alloy installer signed with a valid EV certificate and packed with VMProtect. It steals browser and desktop credentials and gives the actor a reverse shell and proxy.
  • Neo-reGeorg tunnels (tunnel.jsp, tunnel.jspx) for moving into the internal network.
  • MeshAgent for persistent access on Linux, calling out to domains built to look like Microsoft services.

ShinyHunters makes money through data theft and extortion. Any organization with confirmed web shells should plan for a ransom demand and possible publication of stolen data. The group has also claimed a breach of FBI job portals through a PeopleSoft zero-day; the FBI has said it is investigating. Some reports link that claim to this vulnerability, but neither the FBI nor Google has confirmed it.

What to do now

Patching and path-based blocking are not interchangeable, and this activity shows why. Defenders running PeopleSoft should take the following steps:

  1. Patch. Apply Oracle’s June 10 fix on every PeopleSoft node, including nodes behind load balancers. WAF path rules are not a substitute.
  2. Following Oracle’s guidance, disable the Environment Management Hub service in multiserver configurations, or remove the PSEMHUB application entirely in single-server configurations.
  3. Check that your WAF and reverse proxy decode and normalize the path before matching. Test with /%50SEMHUB/ and mixed-case variants, and confirm /PSEMHUB/hub does not answer from outside your network.
  4. Search web, proxy, and WebLogic logs from May 27 onward for POST requests to /PSEMHUB/, /%50SEMHUB/, and other encoded forms.
  5. Look for unexpected .jsp, .jspx, or .exe files under <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/ on every WebLogic node, not only the first one you find.
  6. Alert on WebLogic Java processes starting cmd.exe, PowerShell, /bin/sh, or /bin/bash.
  7. If you find anything, treat it as an intrusion. Preserve evidence, rebuild the host, and rotate every credential the PeopleSoft and WebLogic accounts could read, database connection strings included.

These checks add to the gateway indicators in our June analysis, which still apply.

How TrendAI™ protects customers

TrendAI Vision One™ TippingPoint™ filter 47529 covers this attack. It detects the unsecure deserialization at the heart of it: an unauthenticated POST of a serialized Java object to the PSEMHUB Hub endpoint. TippingPoint percent-decodes the URI before matching, so /%50SEMHUB/ is inspected as /PSEMHUB/ and the encoding trick gets the attacker nothing.

CVE-2026-35273 has been used as a label for more than one weakness in the same endpoint, so our coverage is split by class. Filter 47502 covers the server-side request forgery described in our June analysis, 47529 covers the deserialization, and 47545 covers code execution. TrendAI Vision One™ Deep Discovery™ Inspector rules 5855 and 5863 also detect these vulnerabilities.

Vulnerability shielding works against this actor only when the rule decodes the request the same way the application does, which is how TippingPoint handles it.

Indicators of compromise

The list of indicators of compromise (IoCs) can be found here.