By ByteBot
ShinyHunters applied for WAF entry with a single altered character — and it keeps working. The group (tracked by Mandiant as UNC6240) renewed its mass exploitation of CVE-2026-35273 in Oracle PeopleSoft this week, three months after Oracle shipped the emergency patch. The reason? Organisations that applied WAF rules as an interim fix in June are finding those rules trivially bypassed. One percent-encoded P is all it takes.
What the Vulnerability Is
CVE-2026-35273 (CVSS 9.8) is an unauthenticated remote code execution flaw in Oracle PeopleSoft PeopleTools 8.61 and 8.62. The vulnerable endpoint is the Environment Management Hub servlet at /PSEMHUB/hub. When an attacker sends a POST request with a crafted OPERATION parameter, the server deserialises it as a Java object before checking authentication. The attacker wins the entire PeopleSoft instance without a valid account.
Oracle patched it on June 10, 2026, as an out-of-band Security Alert — meaning the severity was high enough to skip the quarterly CPU cycle. The zero-day exploitation window ran from May 27 to June 9: thirteen days, during which more than 300 PeopleSoft installations were compromised.
The WAF Bypass: One Encoded Character
After the patch dropped, many teams applied WAF rules to block requests to /PSEMHUB/ as a temporary bridge while they scheduled the patch. This was predictably insufficient. UNC6240 adapted almost immediately.
The bypass is straightforward: instead of requesting /PSEMHUB/hub, attackers request /%50SEMHUB/hub. The %50 is the percent-encoded form of the letter P. WAFs that match rules against the raw request path see /%50SEMHUB/ — no match, request passes. The WebLogic application server behind the WAF decodes the path before routing and sends the request to the PSEMHUB servlet as normal.
This is not a WAF bug. It is a URL normalisation mismatch — a gap between what the security layer inspects (raw bytes) and what the application layer processes (decoded path). The attack class is decades old. Cloudflare normalises paths before WAF rule evaluation by default precisely because of it. Most enterprise WAF deployments do not enable normalisation by default.
Defenders need to block more than the literal string. Variants in active use include /%70SEMHUB/ (lowercase p), mixed-case paths like /pSeMhUb/, and double-encoded forms. The only sustainable fix is to enable “normalise before match” at the WAF or reverse proxy layer — and to patch.
What Attackers Do After Getting In
The attack chain is methodical. Reconnaissance comes first: 5 to 15 POST requests to the encoded endpoint, each containing a serialised Java object. Unpatched servers return OS information in the response. No files are written, no services disrupted. Attackers compile a validated target list and return.
Exploitation follows one of two paths. The file-writing path deploys JSP web shells (x.jsp for command execution, u.jsp for chunked binary uploads, tunnel.jsp for SOCKS5 proxying) into the PSEMHUB web application directory. The fileless path executes commands in-memory via the deserialization gadget chain and returns output directly in the HTTP response — no disk writes, no file-based detection.
From there, UNC6240 installs the SIDEEYE backdoor: a 5.2 MB executable masquerading as a Light Alloy media player installer, signed with an Extended Validation certificate (since revoked), protected by VMProtect 3. SIDEEYE communicates with its C2 server over raw TCP, exfiltrates credentials, and establishes a persistent reverse shell. On Linux hosts, MeshCentral agents are deployed to /tmp under infrastructure dressed as Microsoft Azure services.
The end goal is data theft and extortion. HR records, payroll data, and student records are packaged into compressed archives and transferred out. UNC6240 has an established pattern of following access with ransom demands, documented in Mandiant’s September 26 report.
Who Is Exposed
Around 9,500 organisations run Oracle PeopleSoft, concentrated in higher education, healthcare, government, and manufacturing — exactly the sectors handling the sensitive data UNC6240 targets. Any installation where PSEMHUB is accessible from the internet and the June patch has not been applied is actively at risk. Organisations that patched their WAF rules but not the software are specifically the current target population.
What to Do, in Order
First: patch. Apply Oracle’s June 10, 2026 Security Alert for CVE-2026-35273. WAF rules are not a substitute — they have already been bypassed at scale.
Second: disable or remove PSEMHUB. On multi-server deployments, disable the Environment Management Hub service. On single-server deployments, remove the PSEMHUB application entirely. PSEMHUB should not be internet-accessible in any production PeopleSoft deployment.
Third: hunt for existing compromise. Search WebLogic access logs for /%50SEMHUB/, /%70SEMHUB/, and other encoded variants. Check the PSEMHUB.war directory for unexpected files: x.jsp, u.jsp, u2.jsp, tunnel.jsp, tunnel.jspx, and any .exe binaries. Look for large archive files in web-accessible directories.
Fourth: rotate credentials. PeopleSoft service accounts have access to database connection strings, Integration Broker credentials, and potentially cloud credentials. If you cannot rule out compromise, rotate all of them.
Fifth: fix your WAF. Enable path normalisation — specifically “normalise before match” — on your WAF or reverse proxy. Block the known attack controller IPs: 5.199.162.157 (scanner), 162.219.30.165 (SIDEEYE C2), 104.219.234.138 (exfil staging). BleepingComputer’s coverage has additional IOCs and detection guidance.
The patch has existed for three months. The organisations being compromised today are those that treated a WAF rule as a long-term solution. It was not. If you run PeopleSoft and have not applied the June 2026 patch for CVE-2026-35273, stop reading this and go patch.
