Oracle patched CVE-2026-35273 back in June, and ShinyHunters had been using it as a zero-day before that. So why am I writing about it now? Because Bobby Gould at the Zero Day Initiative (ZDI) published the full breakdown on October 20, The Hacker News picked it up this week, and it turns out that one CVE is really three flaws chained together. Each one teaches something.
The Chain
PeopleSoft PeopleTools 8.61 and 8.62. CVSS 9.8, unauthenticated, network reachable.
- SSRF in the Integration Gateway (PSIGW). The attacker controls where a request gets forwarded and what's in it, and the handler doesn't check the destination.
- Loopback is trusted by default. The SSRF points at 127.0.0.1, and the Environment Management Hub (PSEMHUB) ships with loopback already in its
allowedhosts.properties. So the attacker's request looks local, and local is trusted. - Code execution. ZDI describes two routes: a log-write command that drops a web shell anywhere on disk, or a malicious XML file read by Java's XMLDecoder when the service starts, which needs no web shell at all.
ZDI says it's working with Oracle to give each flaw its own CVE.
How It Was Used
Per Google Threat Intelligence Group and Mandiant, UNC6240 (ShinyHunters) hit PeopleSoft between May 27 and June 9, mostly universities, before Oracle's June 10 out-of-band alert. Then a bigger wave in September, across technology, IT services, healthcare, agriculture, transportation and government, with dozens of systems affected. It's in CISA's KEV catalog.
My favorite detail, in the sense that it made me wince: requests to /%50SEMHUB/ (the first letter URL-encoded) slipped past WAF rules that blocked /PSEMHUB/. Mandiant says plainly that path-based WAF blocking isn't a substitute for the patch.
Three Lessons in One CVE
- "Internal" is not a security boundary. The whole chain works because one component trusts requests from localhost. SSRF exists to make an attacker look like localhost. Any time a service says "it's fine, only local callers can reach this," ask what can make a request on its behalf.
- Signature rules are a speed bump. If your protection is a string match, the attacker's job is to find a different string. Useful for buying a day. Not a fix.
- ERP is the data. ShinyHunters runs data theft and extortion. PeopleSoft holds student records, HR data and payroll. That's why they bothered.
What To Do
- Apply Oracle's June 10 security alert fix and stay on a supported PeopleTools release.
- Can't patch yet? Oracle's alert says to disable the Environment Management Hub service (multi-server) or remove the PSEMHUB application (single-server). The Hacker News reports normal user sessions keep working.
- Don't expose PeopleSoft to the whole internet. Put the integration gateway and admin paths behind identity-aware access, and keep only what users truly need public.
- Hunt. Look for unexpected files in PeopleSoft web directories and requests to PSEMHUB paths, encoded or not. Mandiant says to treat hosts with web shells as compromised, preserve evidence, and rotate any credentials reachable from the PeopleSoft tier.
- Plan for extortion. If you were exposed during either wave, assume data may have left, and get your legal, comms and incident response folks talking before an email shows up.
Bottom Line
One CVE, three mistakes: no destination check, trusting localhost, and an admin feature that writes files wherever it's told. Patch it, take the hub off the table, and go look for anything already sitting in your web directories.
Sources: The Hacker News, ZDI write-up, Oracle security alert, Google Threat Intelligence Group, and Mandiant on the September wave