PeopleSoft WAF bypass: one encoded character beats the rule

In June, ShinyHunters ran Oracle PeopleSoft CVE-2026-35273 as a zero-day. A lot of shops responded the fast way: put a WAF rule in front of the vulnerable endpoint and schedule the patch for later. Google's Mandiant reported this week that the group is back in mass exploitation, and the bypass was one encoded character.

What actually happened

Per Google Cloud Threat Intelligence and BleepingComputer:

• The trick is percent-encoding. UNC6240 requests /%50SEMHUB/ instead of /PSEMHUB/. %50 is the encoded form of a capital P. String-matching WAF and reverse-proxy rules compare the literal path, see no match, and pass it through. The PeopleSoft application server then decodes the path and routes the request to the Environment Management Hub exactly as before.
• The bug itself is unchanged. CVE-2026-35273 is a CVSS 9.8 unauthenticated remote code execution flaw in PeopleTools. Oracle shipped an out-of-band alert on June 10, 2026 — we wrote up the original zero-day here.
• The new wave is wider than the first. Google reports web shells on dozens of systems worldwide across higher education, technology, IT services, healthcare, agriculture, transportation, and government — the June campaign was mostly universities. BleepingComputer lists JSP web shells named x.jsp, u.jsp, u2.jsp and tunnel.jsp, plus SIDEEYE backdoors and Neo-reGeorg tunneling for lateral movement.
• Mandiant's guidance is to patch. Apply the Oracle security alert, stay on a supported PeopleTools release, and disable the EMHub service or remove the PSEMHUB application if you do not use it for patching.

Why a WAF rule is not a patch for your business

A WAF and a patch do different jobs. A patch removes the vulnerable code path. A WAF guesses which requests want to reach it. That guess is written in strings, and strings have more spellings than your rule has lines. Percent-encoding is the cheapest of maybe a dozen ways to spell the same path — case variation, double encoding, path traversal, and alternate separators are all sitting right behind it.

Virtual patching is legitimate. It buys you the weekend. What burned these organizations was treating it as the destination: the WAF rule went in, the ticket got closed, and the patch never shipped. Three months later the same attacker spent five minutes on an encoder and walked back in.

If you run PeopleSoft, do this today. Patch to a supported PeopleTools version. Then grep WebLogic access logs for /PSEMHUB/ and its encoded variants, and treat any 200 as an incident until you have proven otherwise. If a compensating control has to stay in place, make it match after URL normalization rather than on the raw path, and remove the PSEMHUB component entirely if nothing depends on it. Code you deleted cannot be reached by a clever spelling.

Sources: Google Cloud Threat Intelligence: ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft, BleepingComputer.