ShinyHunters' PeopleSoft Zero-Day Was Three Chained Flaws

If you patched CVE-2026-35273 in June and moved on, the question worth asking this week is a simple one: patched against what, exactly? According to the researchers who reported the bug to Oracle, the critical PeopleSoft flaw ShinyHunters exploited as a zero-day for months is not one vulnerability but three, chained across two separate components. Oracle fixed all of them under a single identifier. Whether a single-identifier patch tells you enough to verify coverage is the uncomfortable part of this story.

The short answer: if you applied Oracle's out-of-band fix, you closed all three holes, because one patch covered them. But the identifier alone doesn't tell you that, and it tells you nothing about whether someone got in before you patched. On that second point, the evidence is not reassuring. Mandiant's guidance assumes compromise persists past patching. So does mine.

The timeline: zero-day for two weeks, under-reported for four months

Lay the dates out and the shape of the incident gets clearer. Day 0 in practical terms was May 27, when Mandiant and Google Threat Intelligence Group say the group they track as UNC6240 — better known as ShinyHunters — began exploiting the flaw, mostly against universities. That activity ran through June 9. On June 10, Oracle shipped an out-of-band security alert carrying CVE-2026-35273, a 9.8 CVSS, unauthenticated, network-reachable remote code execution bug in PeopleSoft Enterprise PeopleTools versions 8.61 and 8.62. Everything before that date was a zero-day, full stop.

The flaw landed on CISA's Known Exploited Vulnerabilities catalog, which it should have. In early June, ShinyHunters told The Register it had breached more than 100 organisations through the bug. Then, in September — roughly three months after the patch — Mandiant documented a second, larger wave. Targeting spread well beyond education into technology, IT services, healthcare, agriculture, transport and government, with web shells deployed on dozens of systems worldwide. A patched vulnerability with a growing victim count usually means one of two things: slow patching, or attackers keeping access they gained earlier. Here, it looks like both.

This week, the Zero Day Initiative's Bobby Gould published the breakdown that reframes the whole incident, as The Hacker News reported. ZDI's team — Gould with TrendAI researchers Minh Giang and Lucas Miller — reported three distinct vulnerabilities across two PeopleSoft components. Oracle patched them under the one June CVE. ZDI says it is working with Oracle to assign each flaw its own identifier; as of this week, CVE-2026-35273 remains the only one on record.

Step by step: how the chain actually worked

Two components matter, both running as separate web applications. The Integration Gateway (PSIGW) handles messaging with outside systems. The Environment Management Hub (PSEMHUB) is an internal admin interface that is only supposed to answer trusted hosts. The chain is boring in the way the worst chains usually are — no exotic primitives, just a trust decision that shouldn't have shipped.

1. Step one — the SSRF in PSIGW. An attacker sends a request to the gateway's listening connector and controls both the destination address and the full payload forwarded to it. ZDI says the handler performs no check that the destination is legitimate. On its own, limited. It matters because of what it can reach.
2. Step two — the loopback trust bypass. PSEMHUB decides who to trust using a file called allowedhosts.properties. That file ships with 127.0.0.1 already on the list. Point the SSRF at loopback, and the forged request arrives looking like it came from the machine itself. Trust check passes. The internal interface Oracle meant to wall off is now reachable from the internet.
3. Step three — code execution, two ways. Option A: abuse a PSEMHUB command designed to write log entries. The caller controls file contents and the exact path on disk, so write a web shell into the application directory and execute as the PeopleSoft service account. Option B: drop a malicious XML file that PSEMHUB parses with Java's XMLDecoder at next service start — code execution without planting a shell at all. The second path leaves noticeably less for standard detection to catch.

Note what isn't here. Nothing in this chain required novel exploit development at the point of attack. SSRF into a loopback-trusted admin interface is a pattern incident responders have been writing up for years. ZDI put its finger on the design decision at the centre: default-allowing loopback makes the trust check worthless the moment any SSRF exists. If your compensating control was a network rule assuming PSEMHUB could only be reached locally, that assumption died with step two.

The WAF rule that wasn't

The September wave included a detail that should annoy every team that treated perimeter filtering as mitigation. Mandiant found ShinyHunters sidestepping WAF rules that blocked the /PSEMHUB/ path by URL-encoding a single character — requesting /%50SEMHUB/ instead. Many WAF rules match the path as plain text; the PeopleSoft server decodes it and serves the page. One character. That's the gap between having a rule on paper and an admin interface sitting on the open internet.

Mandiant is explicit that path-based WAF blocking is not a substitute for patching. I'd go further: if your only telemetry on this issue was a WAF rule matching the literal path, your logs may show nothing at all while the attack succeeded. When could this have been caught? At the gateway, if outbound request destinations were logged and alerted on — SSRF to 127.0.0.1 from a connector is not normal traffic. At the file system, when a new file appears in the application directory. At service restart, when XMLDecoder ran something it shouldn't. Each stage had a detection opportunity. Each required looking at the host, not the edge.

What one CVE hides, and what patching doesn't fix

Does the single-identifier patch tell defenders enough to verify they're covered? Partially. Oracle's June fix addressed all three issues, so a fully patched system has the chain closed — that much is confirmed by the fact that the alert exists and ZDI's analysis describes what it closed. What's confirmed stops there, though. What remains unknown is whether applying the patch removes access an attacker already established. Oracle's alert doesn't address it. Mandiant's guidance — hunt for web shells, treat any host with a shell as compromised, preserve evidence, rotate every credential reachable from the PeopleSoft tier — is written on the assumption it does not. That assumption is correct. Patching closes the door. It does not evict anyone already inside, and ShinyHunters' business model is to be inside: steal the data, then demand payment.

There's a broader verification problem in how this was disclosed. Three flaws, two components, one CVE. A scanner checking for CVE-2026-35273 coverage will tell you the patch is applied; it won't tell you which of the three weaknesses it remediated, or whether your allowedhosts.properties still trusts loopback, or whether your gateway still forwards arbitrary payloads. Separate CVEs, which ZDI is coordinating with Oracle to assign, would at least let vendors and security teams map fixes, detections and mitigations to specific weaknesses instead of a monolithic identifier. Until that happens, a claim of having patched 35273 is a statement about intent, not a verification of posture. If that pattern sounds familiar — attackers chaining an auth bypass quietly for months while defenders trusted a single fix — the Qilin and Inc ransomware crews' PAN-OS campaign ran on the same logic.

The work this week

The fix and response guidance here comes from Oracle and Mandiant, not ZDI, whose analysis covers the flaw itself. In order of priority: apply the out-of-band fix for CVE-2026-35273 and stay on a supported PeopleTools release. If you genuinely can't patch, Oracle's alert says to disable the Environment Management Hub service in multi-server setups or remove the PSEMHUB application in single-server ones — restricting these admin endpoints doesn't break normal user sessions. Then, for any instance that sat unpatched and internet-reachable between late May and whenever you fixed it, treat it as a candidate intrusion: image or preserve the host, search application directories for web shells, and rotate every credential the PeopleSoft tier could reach. Prepare for an extortion email; that's how this group monetises.

The lesson isn't that Oracle shipped three bugs under one CVE, though it did. It's that the chain only worked because of a default nobody questioned — loopback on a trusted-hosts list — and that every compensating control layered on top of that default, from firewall assumptions to WAF path rules, failed in the same quiet way. Pull your gateway logs. If PSIGW ever forwarded a request to 127.0.0.1, you already have your answer about whether patching was the end of this incident or the middle of it.