The ShinyHunters crew spent nearly two weeks burning an unpatched Oracle PeopleSoft flaw before anyone published an advisory, and universities took the brunt. Here is what CVE-2026-35273 actually exposes, how the attack chain worked, and the exact endpoints and log entries defenders need to check today.
The ShinyHunters extortion crew broke into enterprise systems through an unpatched Oracle PeopleSoft flaw, stole data, and demanded payment to keep it private. The campaign hit universities hardest, and the attackers had a head start: Google's Mandiant attributes the activity to the group it tracks as UNC6240 and dates it between May 27 and June 9, while Oracle did not publish its advisory until June 10. For that entire window, the bug was a true zero-day.

The vulnerability, CVE-2026-35273, is a remote code execution bug in PeopleSoft Enterprise PeopleTools, rated 9.8 out of 10. It requires no login and no user interaction. An attacker with network access over HTTP can take over the server outright. The flaw lives in the Updates Environment Management component, the piece behind the Environment Management Hub, known internally as PSEMHUB. Oracle lists PeopleTools 8.61 and 8.62 as affected and warns that earlier, unsupported versions are probably vulnerable too. Credit for the report goes to researchers from TrendAI Zero Day Initiative and TrendAI Research.
If you run PeopleSoft with the Environment Management Hub reachable from outside your network, that is your exposure. The immediate move is to lock those endpoints down before you do anything else.
What the attackers actually did
The operational detail became public because the attackers left their own infrastructure exposed. Researcher @nahamike01 flagged the open directories publicly, and Mandiant triaged five sequential IP addresses running Python's SimpleHTTP server on port 8888. Those servers exposed the staging files in plain view: a shared .bash_history, custom MeshCentral remote-management agents disguised as Microsoft Azure binaries, and a lateral-movement script.
The agents called home to a command-and-control server at azurenetfiles.net, a domain chosen to mimic Azure NetApp Files. The lateral-movement script, named [victim]_fanout.sh, spreads over SSH by spraying a hardcoded list of usernames and passwords against internal hosts pulled from /etc/hosts. It then drops a marker file, README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT, into PeopleSoft directories. The command history shows data compressed with zstd and an outbound SSH connection to the server hosting the public mirror of the ShinyHunters leak site.
That level of visibility into a live extortion operation is rare, and it gave defenders a precise list of indicators to hunt for rather than guesswork.
The scale, and who got hit
Mandiant notified more than 100 organizations whose IP addresses matched vulnerable endpoints. Sixty-eight percent were in higher education, most of them in the United States. Some blocked the activity in time; others were compromised and had data posted to the leak site.
The University of Nottingham is one of the first confirmed victims. Have I Been Pwned has counted roughly 455,000 unique email addresses in the leaked set, covering current students and alumni. The exposed records include names, addresses, phone numbers, passport numbers, and sensitive details on ethnicity and disabilities. The university has confirmed the breach. ShinyHunters says victim outreach has only just started and that it has not yet posted most of the organizations it claims, so expect more names to surface.
Mitigation comes first, patching second
Oracle's advisory points to a patch availability document behind a support login, and whether a complete fix is broadly available is still unclear. Mandiant CTO Charles Carmakal confirmed exploitation in the wild, though Oracle has not said whether it has observed exploitation itself. Until you confirm a patch exists for your version in My Oracle Support, the guidance centers on mitigation.
For multi-server setups, disable the Environment Management Hub service. For single-server setups, remove the PSEMHUB application outright. If you cannot do either, block external access at the perimeter to /PSEMHUB/* (especially /PSEMHUB/hub) and /PSIGW/HttpListeningConnector. Restricting these endpoints does not break normal user sessions, so there is little reason to delay.
One caution from Mandiant carries weight here: web application firewall body-inspection rules alone are not enough, because they can be bypassed. Treat a WAF rule as a speed bump, not a wall.
Hunt for an existing compromise
Blocking the door does nothing if someone is already inside. Mandiant's hunting guidance gives defenders concrete artifacts to check:
- WebLogic access logs showing external POST requests to
/PSEMHUB/hubor/PSIGW/HttpListeningConnector. - Unexpected
.jspfiles under thePSEMHUB.warweb application directory. - Odd folders named
logs,persistantstorage, orscratchpadunder the PSEMHUB paths. - Recently changed
.xmlfiles under the web doc root'senvmetadata/data/environment, which can be abused for XMLDecoder persistence that fires on the next restart. - Outbound SMB traffic on port 445 from PeopleSoft hosts to external destinations, which the exploit chain may use to capture machine-account NetNTLM hashes.
The XMLDecoder persistence detail matters because it survives a restart, so a host that looks clean today can reactivate the moment it reboots. Check those XML files even if everything else looks normal.
Why this campaign reads differently
The method is the bigger tell. ShinyHunters has recently leaned on vishing, stolen tokens, and weak access controls to pull data from SaaS and education platforms, from Salesforce customers to Canvas. A server-side zero-day in on-premises ERP software is a clear step up from that playbook, aimed at the same data-rich targets but reached through a far more technical route.
That raises the open question security teams should sit with. Was this a one-off, a borrowed zero-day used opportunistically against a juicy target set, or the start of ShinyHunters moving into ERP exploitation as a repeatable tactic? ERP systems hold exactly the kind of structured personal and financial data that extortion crews monetize best, and PeopleSoft's footprint across universities, government, and large enterprises makes it an attractive return on a single bug.
For now, the practical answer for anyone running PeopleSoft is the same regardless of the group's long-term plans: assume the endpoints are being probed, lock down PSEMHUB, work through the hunting checklist, and apply Oracle's update the moment it lands for your PeopleTools version. The attackers had a two-week lead. Closing that gap is the whole job this week.

Comments
Please log in or register to join the discussion