Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

Oracle PeopleSoft Zero-Day Exploited by ShinyHunters Was Actually Three Chained Flaws

The PeopleSoft bug patched in June as CVE-2026-35273 is really an SSRF, a default loopback trust and an arbitrary file write chained into unauthenticated remote code execution. Here is how the chain works, who is being hit and what to do.

4T4Tify Team4Tify
Oct 28, 2026·6 min read
Oracle PeopleSoft Zero-Day Exploited by ShinyHunters Was Actually Three Chained Flaws

Oracle PeopleSoft Zero-Day Exploited by ShinyHunters Was Actually Three Chained Flaws

The critical Oracle PeopleSoft vulnerability that the ShinyHunters extortion group has been abusing since late May is not a single bug. Technical detail now available shows that CVE-2026-35273, the identifier Oracle used when it shipped an emergency fix on 10 June, covers three separate weaknesses across two PeopleSoft components. Chained together, they let an attacker with no credentials run commands on the server.

Separate CVE identifiers for each flaw are in the works, but for now the June identifier is the only one on record. Defenders tracking "one CVE" should understand they are really dealing with a chain.

What happened

CVE-2026-35273 affects PeopleSoft PeopleTools 8.61 and 8.62, scores 9.8 on the CVSS scale and allows unauthenticated takeover over the network. Oracle fixed it in an out-of-band security alert on 10 June, and the flaw is now listed in CISA's Known Exploited Vulnerabilities catalog.

The fix came too late for the first victims. Activity attributed to ShinyHunters (also tracked as UNC6240) exploited the bug between 27 May and 9 June, mostly against universities. Because that predates Oracle's advisory, it was a true zero-day for the entire window. A second, larger wave in September reached beyond education into technology, IT services, healthcare, agriculture, transport and government, hitting dozens of systems worldwide.

How the chain works

Two web applications are involved. The Integration Gateway (PSIGW) exchanges messages with external systems and is meant to be reachable. The Environment Management Hub (PSEMHUB) is an internal admin interface that is only supposed to answer trusted hosts.

  1. Server-side request forgery in the gateway. PSIGW's listening connector accepts a request and forwards it, and the caller controls both the destination address and the full payload. Nothing checks whether the destination is legitimate.
  2. A default that trusts loopback. PSEMHUB decides who to trust by checking the requester against a file named allowedhosts.properties. That file ships with 127.0.0.1 already on the list. Point the SSRF at the local loopback address and the request looks like it came from the machine itself, so the trust check passes and the "internal" hub is suddenly reachable from the internet.
  3. Arbitrary file write inside the hub. With the hub reachable, a command intended for writing log entries lets the caller choose both the file content and the exact path on disk.

From there, two routes lead to code execution. The direct one drops a web shell into the application directory and runs commands as the PeopleSoft service account. The quieter one writes a malicious XML file that the hub parses with Java's XMLDecoder the next time the service starts, running attacker code on restart without ever leaving a web shell behind. That second path gives standard detection much less to catch.

Why it matters

The core lesson is a design one: a trust check based on source IP is worthless once an SSRF exists on the same host, and the loopback entry in the default allow-list made it worthless out of the box. Organizations that assumed a firewall in front of PSEMHUB had them covered were wrong, because the hostile request arrives from inside.

The September wave also showed how fragile virtual patching can be. Web application firewall rules that blocked the plain /PSEMHUB/ path were bypassed by URL-encoding a single character, requesting /%50SEMHUB/ instead. Many WAF signatures match the literal text, while the PeopleSoft server happily decodes it and serves the page.

Finally, ShinyHunters' playbook is data theft followed by an extortion demand, so a compromised PeopleSoft host is a breach with a ransom note attached, not just an availability problem.

What to do

  • Patch. Apply Oracle's security alert fix for CVE-2026-35273 and stay on a supported PeopleTools release. Path-based WAF blocking is not a substitute for patching.
  • If you cannot patch immediately, disable the Environment Management Hub service in multi-server deployments, or remove the PSEMHUB application in single-server ones. Restricting these admin endpoints does not break normal user sessions.
  • Hunt for the quiet path. Look for unexpected JSP files in the PSEMHUB web directory and for unexpected or recently modified XML files in the environment metadata folder, which is where the delayed-execution payload lives.
  • If you may already be compromised, treat any host with a web shell as fully compromised, preserve evidence, and rotate every credential reachable from the PeopleSoft tier: database accounts, integration credentials, service accounts and stored API keys. Prepare for an extortion attempt.
  • Do not assume the patch evicts an intruder. Applying the fix closes the door, but nothing in the vendor guidance says it removes access an attacker has already established. Credential rotation and web-shell hunting are built on the assumption that it does not.

Chained weaknesses like this one, where each piece looks tolerable on its own, are exactly what a scanner checking for a version number cannot tell you about and what a well-scoped penetration test is designed to surface. Our team's penetration testing engagements exercise SSRF-to-internal-service pivots, default trust assumptions and WAF bypasses against externally exposed business applications such as PeopleSoft, so the chain is found by us rather than by the next extortion crew.

SHARE