Threat IntelligenceVulnerability ManagementIncident Response
In June, Oracle shipped an out-of-band fix for CVE-2026-35273, a CVSS 9.8 flaw in PeopleSoft PeopleTools. Not every organisation could install it right away. PeopleSoft runs payroll, HR and student records, and a PeopleTools patch usually needs a change window, a regression test and a weekend. So a lot of teams did what security teams usually do while they wait: they put a rule in the web application firewall (WAF) that blocked the vulnerable path, /PSEMHUB/.
On 26 September, Mandiant and Google Threat Intelligence Group reported that the extortion group ShinyHunters (tracked as UNC6240) is back, exploiting the same flaw across dozens of systems. It gets past those rules by changing one character. It sends /%50SEMHUB/ instead of /PSEMHUB/. %50 is the URL encoding for the letter P.
The WAF compared the raw text and saw no match. PeopleSoft decoded the path, saw /PSEMHUB/, and passed the request to the vulnerable servlet.
The flaw. CVE-2026-35273 is a missing-authentication bug in the Environment Management Hub (EMHub), a PeopleTools component used to manage multi-server installs. Anyone who can reach /PSEMHUB/hub can send it a serialised Java object, and the server will deserialise it without asking who sent it. That gives remote code execution with no login. PeopleTools 8.61 and 8.62 are affected.
The first wave. Mandiant says ShinyHunters exploited the flaw as a zero-day from 27 May to 9 June 2026, mostly against universities. Oracle published its security alert on 10 June. CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 12 June, with a remediation deadline of 15 June. Mandiant notified more than 100 organisations with exposed endpoints at the time.
The second wave. The current campaign reaches beyond education: technology, IT services, healthcare, agriculture, transportation and government. Mandiant describes it as mass exploitation, and the targets have one thing in common. They were reachable, and the only thing in front of the servlet was a string match.
The steps are the same from victim to victim:
POST requests to /%50SEMHUB/hub carrying serialised Java objects. An unpatched server responds with its operating system and keeps running normally.PSEMHUB.war directory. x.jsp runs hex-encoded commands. u.jsp uploads larger files in 150 KB pieces to get around request-size limits.Ple64.exe, disguised as a Light Alloy media player installer and signed with a valid (now revoked) EV certificate, loads a backdoor Mandiant calls SIDEEYE. It steals browser and application credentials and gives the attacker a reverse shell and proxy.tunnel.jsp, tunnel.jspx) send SOCKS traffic over HTTP, so the attacker can reach the internal network through the web server./tmp under the PeopleSoft service account. Earlier deployments reported to domains made to look like Microsoft's, such as microsoft-entra.net and azurenetfiles.net. The September deployments use winmanage-me.network.About a quarter of the commands Mandiant recorded ran as root or NT AUTHORITY\SYSTEM, because some WebLogic installs run with those privileges. The rest ran as the PeopleSoft or WebLogic service account. That account can read psappsrv.cfg, which holds the database connection strings for your HR, payroll and student data.
ShinyHunters' business model is data theft followed by extortion. Mandiant tells victims to expect a ransom demand and to watch leak sites.
This is not really a PeopleSoft story. It's a story about two components reading the same request differently.
A WAF rule written as "block paths containing /PSEMHUB/" checks the bytes as they arrived. The application server decodes the path first, and then decides where the request goes. If the rule and the server disagree about what the path is, the attacker only has to find a spelling the rule doesn't know about and the server still accepts. URL encoding is the easiest option. Mixed case, double encoding, extra slashes and path parameters are others. Mandiant's guidance says to assume attackers will try "any percent-encoded, mixed-case, or non-normalized variant".
The same mismatch has broken path-based controls for as long as there have been proxies in front of applications. It keeps coming back because a string-match WAF rule is quick to write when a CVE drops and seems to work when you test it with the path from the advisory. You tested the spelling you knew about.
There is a second problem, and it's about time. A WAF rule is meant to hold the line for a few days until the patch goes in. Oracle's fix shipped on 10 June. This campaign is happening in late September. For any organisation it hits, the temporary fix has been the only fix for more than three months, and nobody went back to test it against a determined attacker.
Mandiant says it directly: WAF rules and path blocking are not substitutes for patching.
If you run PeopleSoft:
/%50SEMHUB/, /psemhub/ and //PSEMHUB/, not only the path in the advisory./PSEMHUB/, especially POST requests to /hub and requests for .jsp files from outside IP addresses. Search back to May. If the rule was bypassed, the WAF log shows an allowed request that looks harmless..jsp, .jspx or .exe files in PSEMHUB.war/ and PORTAL.war/, specifically x.jsp, u.jsp, tunnel.jsp, tunnel.jspx and Ple64.exe.winmanage-me.network, 5.199.162.157, 104.219.234.138 and 162.219.30.165.psappsrv.cfg, Integration Broker credentials and any cloud keys reachable from the web tier..tar, .tar.gz or .zst files in temporary or web-accessible directories, tar, zstd, rsync or sshpass started by the WebLogic user, and bulk queries against HR, payroll or student tables.For every temporary WAF rule you have:
curl and a few alternate spellings tells you whether the rule matches the path or only one way of writing it.This one is for Obiguard SOC, and there are limits to be clear about. SOC does not patch PeopleSoft, and it does not sit inline as a WAF. Its CVE Radar scans the dependencies in your code repositories, not packaged ERP software like PeopleTools. Oracle's fix and disabling EMHub come first.
What SOC helps with is the step that caught this campaign: reading the logs written behind the filter, alongside the ones written in front of it.
WAF, WebLogic and host logs in one search. SOC ingests logs through the OpenTelemetry Collector, which can tail WebLogic access logs and host logs on the PeopleSoft servers. In Live Logs, a full-text search for EMHUB returns the WAF's "allowed" entry, the WebLogic request that reached the servlet and any process events from the same host together, in time order. The first shows the rule didn't block the request. The second shows what the server actually received.
Alerts from behaviour, not only signatures. SOC raises alerts from changes in log volume as well as rule matches, without you writing detection logic. A burst of POST requests to a management endpoint that normally sees no outside traffic, or a PeopleSoft host whose outbound activity changes after a MeshAgent install, becomes an alert with an evidence timeline linked to the raw events that triggered it.
A record that outlasts the web tier. When a web shell turns up, the question changes from "are we vulnerable?" to "what did they do, and when did it start?" If WebLogic and host logs have been going to SOC since June, the answer is in a copy the attacker could not edit from the compromised server. That is the requirement we wrote about two days ago, after Check Point's log servers were compromised, and it matters just as much when the compromised box is your ERP.
Blocking /PSEMHUB/ at the WAF was a reasonable first step in June. What went wrong is that it was never replaced, and never tested against the spellings a server would also accept.
So the question is not do we have a rule for this CVE? Most teams do. It is: for each virtual patch still running in front of an unpatched system, have you checked that it blocks what the application actually receives, and when is the real fix due?
Explore Obiguard SOC or talk to us about putting your WAF, application and host logs on one timeline, so a request the filter allowed is still visible to the team hunting for it.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →