The critical Oracle PeopleSoft vulnerability that hackers exploited as a zero-day in May and June wasn't a single bug but three separate flaws chained together, according to researchers from the Zero Day Initiative (ZDI) who disclosed the issue this week. Oracle fixed all three under one identifier, CVE-2026-35273, in a June 10 emergency patch, but ZDI says it originally reported three distinct vulnerabilities across two PeopleSoft components and is now pushing Oracle to assign separate CVE numbers to each. The root cause is a server-side request forgery that reaches an internal admin console because PeopleSoft trusts its own loopback address by default, creating a path to remote code execution without any login.

CVE-2026-35273 hits PeopleSoft Enterprise PeopleTools versions 8.61 and 8.62, earning a CVSS severity score of 9.8, which allows an unauthenticated attacker to seize control of the server remotely over the network. The flaw landed on CISA's Known Exploited Vulnerabilities catalog after threat actors, identified by Mandiant and Google Threat Intelligence Group as UNC6240—publicly known as ShinyHunters—began exploiting it between May 27 and June 9, primarily targeting universities. Because that campaign ran before Oracle's June 10 advisory went live, the entire exploitation window counted as zero-day activity. Mandiant documented a second, broader wave in September that expanded beyond education into technology, IT services, healthcare, agriculture, transport, and government sectors, compromising dozens of systems around the world.

ZDI's technical breakdown reveals how the three flaws work in sequence. The attack begins with a server-side request forgery in the Integration Gateway (PSIGW), a component that handles messages from external systems. An attacker sends a request to PSIGW's listening connector and controls both the destination address and the complete payload forwarded, with no validation that the target is legitimate, ZDI explained. That SSRF then reaches the Environment Management Hub (PSEMHUB), an internal admin interface meant to accept connections only from trusted hosts. PSEMHUB checks trust by comparing the requester's address against a file named allowedhosts.properties, which ships with the loopback address 127.0.0.1 already included. The attacker simply points the SSRF at 127.0.0.1, making the request appear to originate from the machine itself, and the trust check passes. From that foothold, ZDI described two paths to code execution: one abuses a PSEMHUB logging command to write a web shell directly into the application directory, while the other plants a malicious XML file that runs attacker code via Java's XMLDecoder when the service restarts. The second technique leaves fewer artifacts for standard detection tools to catch. During the September campaign, Mandiant observed ShinyHunters evading web application firewall rules that blocked the /PSEMHUB/ path by URL-encoding a single character, requesting /%50SEMHUB/ instead; many WAF rules match plain text while PeopleSoft decodes the path and serves the page anyway.

The design flaw at the heart of the issue, according to ZDI, is that permitting loopback access by default renders the trust check useless once the SSRF exists—a lesson that matters for defenders who assumed a firewall rule offered sufficient protection. Oracle and Mandiant both emphasize that path-based WAF blocking is not a substitute for applying the patch. Organizations that can't patch immediately should disable the Environment Management Hub service in multi-server environments or remove the PSEMHUB application entirely in single-server setups, as Oracle's alert recommends; restricting these admin endpoints won't disrupt normal user sessions. For those who suspect they've already been breached, Mandiant advises treating any host with a web shell as fully compromised, preserving forensic evidence, and rotating every credential accessible from the PeopleSoft tier. ShinyHunters is known for data theft followed by extortion demands, so affected organizations should brace for ransom attempts. Neither Oracle's alert nor Mandiant's guidance confirms whether patching alone revokes access an attacker has already secured—Mandiant's recommendation to rotate credentials and hunt for web shells assumes it doesn't. The patch closes the entry point but doesn't automatically evict an intruder who's already inside. Enterprises relying on layered defenses may find that assumption tested when a single misconfigured trust list can unravel multiple protective controls, and patching schedules will need to account for the persistence risk that remains even after the fix is deployed.