Somewhere there is a change ticket that reads “WAF rule deployed, PeopleSoft exposure mitigated,” closed and signed off months ago. That ticket is now wrong, and the people who proved it are running a data-extortion crew.
BleepingComputer reports that ShinyHunters has resumed large-scale exploitation of Oracle PeopleSoft servers via CVE-2026-35273, and the interesting part isn’t a new vulnerability. It’s that the old one never stopped working. The virtual patch did. The exploit didn’t.
What does CVE-2026-35273 actually hand an attacker?
According to Oracle’s advisory, CVE-2026-35273 sits in the PeopleSoft PeopleTools web layer — the servlet stack that fronts the application on WebLogic. Exploited successfully, it lets a remote attacker reach functionality that should be protected and run code in the context of the application server. From there it’s the usual march: dump the datasets PeopleSoft exists to hold — HR records, payroll, student and financial data — and stage it for extortion.
Here’s the part that widens the blast radius: the flaw lives in PeopleTools, the shared runtime under every PeopleSoft application — HCM, FSCM, Campus Solutions, ELM. Your exposure tracks your PeopleTools build, not your application module. Oracle’s Critical Patch Update advisory enumerates the affected release lines — the currently supported 8.6x families — and names the fixed maintenance pack for each. The fix ships as a cumulative PeopleTools patch through Oracle’s quarterly CPU cycle; there’s no registry toggle or config flag that substitutes for it. Apply the build the advisory marks as fixed and confirm it against PSSTATUS (below) — don’t trust the WAF to tell you the code is patched, because it can’t.
The extortion that follows is the ShinyHunters pattern documented across their prior campaigns: steal the data, threaten to publish, pressure the victim directly. ShinyHunters, known for data theft and extortion rather than encryption, brings no ransomware crypter to detect and no clever zero-day here. The novelty is entirely in how they got past the control you thought you had. Don’t let anyone sell you URL encoding as sophistication. It’s on the first page of every WAF-evasion cheat sheet written this century.
Why did the WAF rule fold?
Because most of the rules deployed against this were signatures — literal patterns matched against the raw request. The exploit path contains recognisable tokens, so the rule blocked requests containing those tokens. Fine, until you remember that HTTP is a text protocol with a built-in escape mechanism.
A dot is . or it’s %2e. A slash is / or %2f, or, if the WAF decodes once, %252f — double-encoded, so the firewall sees %2f (harmless text) and passes it, then WebLogic decodes it a second time into the character the exploit needs. The firewall and the app server disagree about what the request says. The attacker only has to satisfy the app server.
The WAF inspects the request it received. The application executes the request it decoded. If those aren’t the same string, your rule is guarding a door nobody’s using.
So what rule actually survives?
Normalise first, match second. Decode the input into its canonical form before you run any signature against it, and do it recursively so double- and triple-encoding collapse to one representation. In ModSecurity / OWASP CRS terms, that means chaining URL-decode transformations onto the rule rather than matching raw bytes:
The load-bearing tokens are t:urlDecodeUni applied twice and phase:2 so the body is available. Better still, stop treating this as a per-CVE signature problem: enable the CRS request-normalisation and protocol-enforcement paranoia levels, and alert on requests where an encoded byte survives to the origin — because a legitimate PeopleSoft client has no reason to double-encode a path.
Are you already compromised?
Signature blocking arriving late means some of these got through when the rule was raw-only. Go read the logs before you congratulate yourself on the fix. Look for encoded traversal and encoded tokens in the WebLogic access logs, then verify your patch level:
Then confirm the actual PeopleTools patch, not the WAF band-aid. Query the instance directly:
Match that release against Oracle’s Critical Patch Update advisory covering CVE-2026-35273 and apply the fixed PeopleTools maintenance pack it lists. Every PeopleTools line still fronting the internet below that build is in scope — the WAF rule was always the compensating control, never the fix.
The verdict
This isn’t “some WAFs are broken.” It’s that signature-only inspection of an encoded protocol was never protection — it was a demo that looked like protection until someone typed a percent sign. Immediate action if you front PeopleSoft with a virtual patch: switch the rule to decode-then-match today, grep the historical logs tonight, and schedule the PeopleTools maintenance pack from Oracle’s CPU this week rather than next cycle. Raw-byte matching is dead. Canonicalisation won. ShinyHunters just sent you the invoice.