Unpatched Oracle bug breached firms across 7 sectors

A critical CVE-2026-35273 (CVSS 9.8) hit Oracle PeopleSoft — but no lock was picked. 💻 Attackers just typed "/%50SEMHUB/" to slip past a WAF filter that only blocked "/PSEMHUB/". One encoded character undid "enterprise-grade" security. Dozens of systems across seven sectors — higher ed, healthcare, HR/payroll — were breached, with an FBI jobs site defaced and personnel data reportedly grabbed. Oracle's patch shipped in June; many never installed it. Is your team patching holes — or just maintaining regex rules?

So here's the thing about the whole "sophisticated hacker" myth: half the time, these villains aren't geniuses. They're just the only ones who read the manual.

Enter ShinyHunters, the group that just turned Oracle PeopleSoft into a drive-thru across at least seven sectors — higher ed, healthcare, government, tech, agriculture, transportation, and HR/payroll. The damage spans "dozens of systems," with the crown jewel being a defaced FBI jobs site on September 22 and an alleged 2–3 TB grab of agent personnel data that Reuters partially verified against credit bureau records.

Let's not bury the lede: this was never a sophisticated bypass. It was a one-character costume change.

The Attack That Wasn't Even an Attack

The vulnerability, CVE-2026-35273, is a critical (CVSS 9.8) unauthenticated remote code execution bug in PeopleSoft's Environment Management Hub (PSEMHUB) — an SSRF chain that lets attackers escalate to admin accounts and grab root on the underlying OS. Oracle shipped the patch on June 10, and CISA flagged active exploitation the same week. Google's own accounting of the campaign notes roughly a quarter of attacker commands executed as root or SYSTEM — full house keys handed out, not a lock picked.

You'd think that would be the end of it.

Nope. ShinyHunters came back in late September and found that most victims hadn't patched. They'd instead bolted a WAF rule onto the front door that simply rejected any request containing the literal string /PSEMHUB/.

And here's the comedy: the attackers typed the 'P' as %50. That's it. /%50SEMHUB/. The WAF's string matcher squinted at it, shrugged, and let it through — because the request was URL-normalized after routing. The firewall never saw the thing it was supposed to block.

So all that "enterprise-grade security"? Neutralized by one percent-encoded character. Billions in security spend, undone by the URL-encoding equivalent of a knock-knock joke.

What Actually Happened

Don't take my word that this was preventable. The timeline wrote itself:

• May 27 — ShinyHunters starts exploiting CVE-2026-35273 as a zero-day against the exact same PSEMHUB component. That was the warning shot.
• June 10 — Oracle ships the patch. CISA confirms active in-the-wild exploitation.
• June 10 — University of Nottingham exposes 40GB of student and financial data; roughly 450,000 student records lose direct access after systems are shut down.
• June 30 — Nissan Americas confirms SSNs and bank details leaked from a May 27–June 9 breach window.
• Late September — ShinyHunters returns to find everyone unpatched and belts out a fresh campaign.

Once inside, the playbook was depressingly standard: 5–15 reconnaissance POSTs to /%50SEMHUB/hub, JSP web shells (x.jsp, u.jsp) for command execution, a trojanized Ple64.exe dropping the SIDEEYE backdoor, and MeshAgent persistence dumped into /tmp. Seven sectors, one CVE, zero imagination required. The only "innovation" was realizing organizations would rather maintain WAF regex rules than apply a patch that shipped three months ago.

"Oh but the forensics!" Sure — one report says the 3.1TB footprint on the Nottingham side was really capped near 105KB of actual extraction. Early-stage scanning, not full seizure. Reassuring, right? Tell that to Nissan's employees hearing their social security numbers floated around, or the insurers whose rating computations briefly stalled while regulators suspended audit feeds.

The PeopleSoft Graveyard

Lest you think Oracle is somehow innocent bystander here, let me introduce you to their encore. Less than two weeks after ShinyHunters went back to school on PeopleSoft, CISA stuffed another Oracle flaw — CVE-2026-46817 — into its Known Exploited Vulnerabilities catalog on July 15. That one's a different critical (CVSS 9.8) unauthenticated bug, this time inside Oracle Payments across versions 12.2.3–12.2.15. Improper privilege management, full take-over of a core financial transaction engine used by thousands of businesses. Under BOD 26-04, the mandate is patch within 24 hours or pull the service. No pressure — it's only the thing moving money between you and your customers.

So Oracle can ship patches with one hand while leaving a second critical hole in the payments module for months in the same window. The corner office calls it a "comprehensive suite." I call it a whack-a-mole franchise.

What's Coming

Expect this to keep going. Mandiant's GTIG is already tracking a "renewal attack cycle" on CVE-2026-35273, with over 58 incidents recorded across multiple continents and expansion toward AWS GovCloud. Attackers iterate on encoding variants faster than IT teams update regex. Every unpatched PeopleSoft 8.61/8.62 instance is a ticking clock. And with 60+ organizations potentially compromised on the HR/payroll side — personnel records, addresses, family details — the blast radius is about payroll, benefits, and identity data, which is precisely the stuff that causes actual harm when it leaks.

So by all means, keep patching your WAF. It's the kind of busywork that photographs well in the quarterly board deck. Just don't be surprised when the next %-encoded character — or the next Oracle payments module — walks right past it, and straight into your employee database.