The WAF blocked /PSEMHUB/. ShinyHunters sent /%50SEMHUB/ instead

The renewed campaign targeted the gap between the security rule and the application

On 25 September 2026, Mandiant and Google Threat Intelligence Group reported renewed mass exploitation of CVE-2026-35273 by UNC6240, also known as ShinyHunters. The vulnerability affects Oracle PeopleSoft Enterprise PeopleTools and allows unauthenticated remote code execution. Oracle assigns it a CVSS 3.1 score of 9.8 and released an out-of-band security alert on 10 June.

The earlier defensive guidance included blocking external access to /PSEMHUB/* when immediate patching or service removal was not possible. The new campaign changed the request to /%50SEMHUB/, where %50 is the URL-encoded representation of the letter P. Some WAF and reverse-proxy rules compared the raw request against the literal string /PSEMHUB/, so the encoded form did not match. WebLogic then decoded the URL and routed it to the vulnerable servlet.

Mandiant says the actor deployed web shells on dozens of systems worldwide across higher education, technology, IT services, healthcare, agriculture, transportation and government. The exact victim count and any stolen datasets were not published.

One decoding step explains the bypass

HTTP infrastructure may inspect a request at several stages. The edge receives a raw path. A WAF may compare that path to block patterns. A reverse proxy or application server may later normalise case, resolve encoded characters and route the decoded result. If the filter and destination do not evaluate the same canonical form, two different strings can become the same application request.

That is what Mandiant observed. The literal path was blocked; the encoded path passed the earlier comparison; WebLogic converted %50 back to P; PeopleSoft served /PSEMHUB/hub. Defenders should assume that attackers will try other percent-encoded, mixed-case or otherwise non-normalised variants rather than treating %50 as the only bypass.

Verification could be quiet; exploitation could be fileless or persistent

Mandiant observed targeted servers receiving five to fifteen POST requests to /%50SEMHUB/hub containing a serialized Java object. An unpatched server could return its operating system without writing a file or disrupting the service, allowing the actor to verify exploitability before choosing the next step.

The exploitation paths then diverged. In one, repeated requests attempted to place JSP web shells such as x.jsp on multiple nodes behind a load balancer. In another, commands executed through the WebLogic Java process and returned output directly in the HTTP response, leaving no JSP file behind. File-creation detections alone therefore miss part of the observed behaviour.

Across compromised instances, Mandiant says one quarter of observed commands ran as root or NT Authority\SYSTEM. Commands running as PeopleSoft or WebLogic service accounts could still reach configuration files, database connection strings and application data.

Observed stages and useful evidence

Stage	Observed behaviour	Evidence to review
Verification	Five to fifteen POST requests to the encoded hub path	WebLogic access logs, source IP, response pattern
Exploit	Java deserialization through the PSEMHUB hub servlet	External POST bodies and Java child processes
Persistence	JSP web shells written into application directories	Unexpected JSP, JSPX or executable files on every node
Fileless execution	Command output returned in the HTTP response	cmd.exe, /bin/sh or bash spawned by WebLogic Java
Follow-on access	Tunnelling, credential access and MeshCentral tooling	Outbound connections, new agents and credential use

Patch first, then hunt as though the WAF may have failed

The durable engineering lesson is canonicalisation before enforcement

Security controls should make access decisions over the same canonical representation used by the protected application. That means normalising and decoding safely before comparison, rejecting ambiguous encodings where possible, and testing alternate representations during validation. It also means accepting the limit of a perimeter rule: even a perfectly normalised block does not repair unsafe deserialization behind it.

The campaign demonstrates why mitigations need expiry dates and owners. An emergency WAF rule should create time to patch, not become a permanent substitute for patching. When the temporary control becomes the long-term plan, attackers can focus on differences between what the filter recognises and what the application accepts.

Key facts