ShinyHunters Bypass PeopleSoft WAF Rules for CVE-2026-35273 Exploits

Mandiant and GTIG track the group as UNC6240. The current campaign demonstrates that UNC6240 adapted to published defensive guidance, targeting organizations that implemented WAF rules but did not patch the vulnerability. Put simply, the attackers read the defenders' guidance and adjusted.

The bug: an unauthenticated RCE in PeopleTools​

CVE-2026-35273 is about as serious as bugs get. It is a remote code execution bug in PeopleSoft Enterprise PeopleTools rated 9.8 out of 10. It needs no login and no user interaction, just network access over HTTP, to take over the server. The flaw is in the Updates Environment Management component, which sits behind the Environment Management Hub (PSEMHUB). Oracle lists PeopleTools 8.61 and 8.62 as affected and says earlier, unsupported versions are probably vulnerable too.

Here's how the timeline went:

• May 27 – June 9, 2026: UNC6240 exploited CVE-2026-35273 as a zero-day, predominantly against higher education institutions.
• June 10: Oracle released an out-of-band Security Alert. BleepingComputer reported the same day that ShinyHunters had used the zero-day to steal data from about 100 organizations.
• June 12: CISA added the vulnerability to its Known Exploited Vulnerabilities catalog, two days after the fix shipped.
• June: Mandiant recommended patching. Where patching or disabling EMHub wasn't immediately possible, it advised blocking external access to /PSEMHUB/* at the perimeter, and noted that WAF body-inspection rules alone were insufficient.
• September 25: Mandiant and GTIG published details of the renewed campaign and the WAF bypass.

The June breaches did real damage. The University of Nottingham was one of the first confirmed victims. Have I Been Pwned counted about 455,000 unique email addresses in the leaked set, along with names, addresses, phone numbers, passport numbers, and details on ethnicity and disabilities.

Section summary: This is a CVSS 9.8, no-login RCE in PeopleTools 8.61/8.62. It was exploited as a zero-day, patched out-of-band in June, and it's in CISA's KEV catalog.

How the %50 trick works​

The bypass is very simple. Where the original attacks requested /PSEMHUB/, the attackers now request /%50SEMHUB/. %50 is just the percent-encoded form of the capital letter P.

Mandiant explains the gap: many WAF and reverse proxy rules match the literal path before URL decoding, while the PeopleSoft application server decodes the request and routes it to the vulnerable servlet. So the perimeter device sees a string that doesn't match its rule and lets it through. Oracle WebLogic then decodes the %50 back to a P and hands the request to the vulnerable endpoint.

In Mandiant's words, this lets the attacker reach the endpoint "on systems whose operators may have believed their WAF rules had mitigated the exposure."

This is an old class of problem: a mismatch between how the security layer reads a request and how the application reads it. Path normalization bugs have been beating string-matching filters for as long as URLs have been encoded. Mandiant's report does not say every WAF fails this way. It describes rules that match the raw path before decoding. A rule that checks the normalized, decoded path is a different thing.

Don't just add %50SEMHUB to your blocklist and call it done, though. Mandiant says defenders should assume attackers may use any percent-encoded, mixed-case, or otherwise non-normalized version of /PSEMHUB/, and should enforce blocking on the normalized path. Adding one variant at a time just restarts the same chase.

Section summary: One encoded character gets past literal-string WAF rules because WebLogic decodes the path after the WAF has already checked it. Block on normalized paths, and treat blocking as a stopgap, not the fix.

What the attackers do once they're in​

Mandiant describes a consistent sequence across targeted environments.

1. Quiet reconnaissance​

Before exploiting a server, the attackers typically send five to 15 POST requests to /%50SEMHUB/hub containing a serialized Java object. On an unpatched server, the response reveals the host operating system without writing files or disrupting service. That's a low-noise way to confirm the server can be exploited. Mandiant notes that on servers that were tested but not yet exploited, these requests may show up in logs with nothing after them. If you find them, treat it as a warning, not a false alarm.

2. Two exploitation methods​

Both abuse Java deserialization in the PSEMHUB hub servlet:

• Web shell deployment: a burst of POST requests followed by new JSP files, such as x.jsp, in the PSEMHUB.war directory. The repetition probably makes sure every node behind a load balancer gets a copy, so check all WebLogic nodes, not just the first one you look at.
• Fileless command execution: command output comes back directly in the HTTP response and nothing is written to disk. On the host, you'd see cmd.exe or /bin/sh spawned by WebLogic's Java process. Detection that only looks for new JSP files will miss this completely.

3. Post-exploitation tools​

For Windows administrators, Ple64.exe is the most important item. Mandiant says the analyzed sample was signed with a valid Extended Validation certificate issued via Sectigo, and GTIG has asked Sectigo to revoke it. Inside is a three-stage chain, with the second stage protected by VMProtect 3, that ends by loading SIDEEYE, a C++ backdoor. SIDEEYE supports browser and desktop credential theft, process and file management, and interactive reverse shell and reverse proxy functions. A valid EV signature on a malicious binary shows that "it's signed" doesn't mean "it's safe."

Access levels matter too. Mandiant reports that a quarter of the attackers' commands ran as root or NT AUTHORITY\SYSTEM. The rest ran under PeopleSoft or WebLogic service accounts, which can still read configuration files, database connection strings and application data.

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. The campaign expanded beyond education into those sectors and also involved SIDEEYE, Neo-reGeorg, and MeshCentral infrastructure.

Section summary: The attackers probe quietly, then either drop web shells or run commands without touching disk. Windows hosts get an EV-signed trojan carrying SIDEEYE, and Neo-reGeorg turns the PeopleSoft server into an entry point to the internal network.

What PeopleSoft admins should do now​

Mandiant's guidance, in priority order:

1. Patch. Apply Oracle's Security Alert fix for CVE-2026-35273. Mandiant says outright that WAF rules and path-based blocking are not a substitute. The patch is available through My Oracle Support (Patch Availability Document CPU187) and in the June 2026 Critical Security Patch Update.
2. Upgrade anything unsupported. No patch exists for releases earlier than 8.61, so organizations running them should upgrade to a supported version.
3. Disable or remove EMHub. Disable the EMHub service in multi-server configurations, or remove the PSEMHUB application entirely in single-server setups, as Oracle advises. Mandiant says EMHub and the Integration Broker listening connector are administrative, system-to-system components, and cutting them off from the public internet doesn't break standard PeopleSoft Internet Architecture (PIA) user sessions. Test that against your own deployment anyway.
4. If you keep a WAF rule as extra protection, match on the normalized path, not the raw string.
5. Hunt in your logs. Search PIA WebLogic access logs for /PSEMHUB/ and encoded variants such as /%50SEMHUB/. Pay particular attention to external POST requests to /hub and requests for unexpected .jsp or .jspx files under PSEMHUB or PORTAL.
6. Audit the filesystem. Check <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/ and PORTAL.war/ for files that didn't ship with the product, including x.jsp, u.jsp, tunnel.jsp, tunnel.jspx and Ple64.exe. Also inspect envmetadata/transactions/ for unauthorized content.
7. Watch process behavior. Alert on cmd.exe, /bin/sh or bash spawned by the WebLogic Java process, especially when it runs things like base64 -d, curl, /dev/tcp, tasklist or start /b.
8. Check network egress. Mandiant lists 5.199.162.157 (scanner and callback receiver), 104.219.234.138 (staging and remote management), 162.219.30.165 (SIDEEYE command-and-control on TCP 3333/3334) and the domain winmanage-me.network. Look for MeshCentral agents you didn't install.
9. If you find a shell, assume full compromise. Preserve evidence and rotate every credential the PeopleSoft tier can read, including database connection strings in psappsrv.cfg, Integration Broker credentials and any cloud credentials reachable from the web tier. Start with hosts where WebLogic runs as root or SYSTEM.
10. Look for data theft and prepare for extortion. Look for large .tar, .tar.gz or .zst archives, rsync/sshpass/zstd activity from service accounts, and bulk queries against HR, payroll and student records tables. ShinyHunters' pattern is to steal data and threaten to leak it, so plan for extortion demands.

Section summary: Patch first, remove EMHub where you can, and hunt for both encoded requests and fileless activity. A patch doesn't remove attackers who are already inside.

The FBI claim: treat it with caution​

The September campaign comes shortly after ShinyHunters claimed a much bigger target. The group told BleepingComputer on September 22 that it used what it called a new PeopleSoft zero-day to get into the FBI Jobs platform and then move into the FBI's AWS GovCloud environment. It claimed to have taken 2 TB to 3 TB of data on current and former employees, applicants and internal systems.

None of that has been verified. BleepingComputer couldn't independently confirm the alleged zero-day, the lateral movement or the amount of data. The FBI confirmed it was investigating claims of unauthorized activity affecting FBIjobs.gov but didn't confirm a breach or any data theft. ShinyHunters has since told BleepingComputer it used this WAF bypass against FBI Jobs, while still insisting it also exploited a "NEW unknown vulnerability in the same PSEMHUB component."

Extortion groups have every reason to exaggerate, since a scarier story brings bigger payments. But one detail should worry defenders even if the FBI story turns out to be inflated: the attackers keep focusing on the same component. If there is a second PSEMHUB bug, patching CVE-2026-35273 while leaving EMHub exposed to the internet would still leave a door open. That's one more reason to disable or remove the component rather than rely on a single patch. Mandiant's report confirms the renewed CVE-2026-35273 campaign and the WAF technique. It does not confirm the FBI claims.

Bottom line​

A WAF rule that blocks a URL path is worth having while you schedule the patch, but it's temporary. ShinyHunters got past these rules with a single encoded letter, and Mandiant has seen the same group read defensive guidance and adapt. PeopleSoft often holds HR, payroll and student records, so the fix is to patch, remove EMHub if you don't need it, and assume any server that sat exposed since May needs a full compromise check.