The PeopleSoft WAF bypass: one encoded letter

On 26 September 2026, Mandiant reported that the extortion group ShinyHunters had gone back to work on Oracle PeopleSoft. The flaw, CVE-2026-35273, is an unauthenticated bug in the Environment Management Hub that hands an attacker code execution on the server and, from there, the whole instance. It is rated 9.8 out of 10 and sits on the United States catalogue of vulnerabilities under active attack. The part worth your attention is not the bug. It is how the attackers walked past the firewalls meant to stop them: they changed one letter of the web address.

What happened

PeopleSoft's Environment Management Hub answers at the path /PSEMHUB/hub. It accepts data and turns it back into live objects without asking who is calling, a pattern known as unsafe deserialization, so a crafted request becomes code running on the server. Mandiant's report ↗ describes a first wave from late May, exploited before a patch existed, then a renewed campaign in September. The targets span higher education, healthcare, transportation and government, and the actors left web shells behind for credential theft and lateral movement. Oracle has issued a patch and an advisory ↗, and the flaw is on CISA's known-exploited catalogue ↗.

One letter past the firewall

By September, many targets had added a firewall rule to block requests to /PSEMHUB/. The attackers stopped sending them. They requested the encoded form /%50SEMHUB/, where %50 is the web-address code for the letter P. The firewall compared the raw text, saw no match, and let it through. The PeopleSoft server then decoded the address, read it as /PSEMHUB/, and served the vulnerable endpoint. Mandiant's guidance is blunt: assume any percent-encoded, mixed-case or otherwise non-normalized spelling of the path, and block on the decoded form.

A firewall matches the spelling of an attack. Only the product can be tested for the behaviour.MATT Research

The firewall was never the control

Mandiant puts it in one line: "WAF rules and path-based blocking are not a substitute for patching." A firewall rule is a guess at what an attack looks like, written as a string to match. It buys time, and teams are right to use it, but it covers only the spellings someone thought of. The control that actually closes CVE-2026-35273 is Oracle's patch, plus turning the Hub off where it is not needed. A team that added the rule and moved on had a green dashboard and an open door.

Your edge and your product disagree

The gap here is general. The thing at your perimeter, a firewall or a proxy, reads a request one way; the application behind it reads the same request another way, after decoding and its own routing. Every place those two readings differ is a place an exploit can live, and edge rules cannot close a gap the edge cannot see. It is the same lesson as why a once-a-year test misses what ships weekly: a control that lives away from the running product measures a proxy for safety.

The rule and the check

Turned into ExploitOps, this is one rule with a check that runs against the live product. Declare: the Environment Management Hub is unreachable from outside, by any spelling of its path. Observe: list every route the application decodes and serves, and mark where the edge and the app read a request differently. Prove: send the blocked path and its encoded, mixed-case and doubly-encoded variants, and confirm the product itself refuses each one, on every release. Fix: apply Oracle's patch, disable the Hub where it is unused, and rotate the credentials the web tier can read. Remember: keep the check, because the next bug will hide behind a different spelling. A rule like this is written in plain English and re-proven every release, and the shape it belongs to lives in the attack library. MATT has no PeopleSoft to defend; the method is the point, and it holds for any product with a firewall in front of it.