The ShinyHunters Wake-Up Call

What CVE-2026-35273 Actually Tells You About Your PeopleSoft Security Posture

A cybercrime group breached more than 100 organizations through PeopleSoft before Oracle even knew the vulnerability existed. Universities. Hospitals. Government agencies. Roughly 300 PeopleSoft instances were compromised, student records stolen, and extortion demands sent.

If you run PeopleSoft, that sentence is supposed to make your stomach drop. And the migration crowd is already using it to make a familiar argument: see, this is what happens when you stay on legacy software. Move to SaaS and let the vendor own the security.

That argument is wrong, and the details of this breach are exactly why. Let me walk through what actually happened, and what it does and doesn’t say about the platform you’re running.

What happened

Between May 27 and June 9, 2026, a financially motivated group called ShinyHunters, tracked by Google’s Mandiant as UNC6240, exploited a previously unknown flaw in Oracle PeopleSoft PeopleTools. Oracle didn’t publish its advisory until June 10. The attacks had been running in the wild for two weeks before anyone outside the attacker’s circle knew the vulnerability existed. This was a true zero-day.

The flaw is tracked as CVE-2026-35273. It carries a CVSS score of 9.8 out of 10. It is unauthenticated, remotely exploitable, and low-complexity. There is no need for login, no stolen credentials, and no user clicking anything. Just network access over HTTP. TrendAI’s Zero Day Initiative, which reported it to Oracle, classified the root cause as server-side request forgery that chains into remote code execution.

The damage was concentrated where it hurts. According to Mandiant, 68% of the notified organizations were in higher education. Overwhelmingly, U.S. colleges and universities are the exact shops that run Campus Solutions, housing student PII, financial aid records, and billing data. The University of Nottingham was among the first confirmed victims; ShinyHunters reportedly stole 40GB covering 450,000 current and former students and posted it to their leak site on June 9 after the university declined to pay. CISA added the CVE to its Known Exploited Vulnerabilities catalog on June 12.

So far, this reads like a vendor problem. Here’s the part that should change how you think about it.

The vulnerability was in the part you forgot was exposed.

The flaw lives in the Updates Environment Management component — the machinery behind the Environment Management Hub, PSEMHUB. Mandiant’s analysis points to two endpoints: /PSEMHUB/hub and /PSIGW/HttpListeningConnector.

Read that again. The breach didn’t come through the front door that your users log in to every day. It came through environment-management plumbing. Most organizations stood up their infrastructure years ago, configured it once, and never thought about it again. The attack only works if that machinery is reachable from an untrusted network.

That is the whole ballgame. Oracle itself describes the vulnerability as easily exploitable and remotely reachable, which makes external exposure the single biggest risk multiplier. The organizations that got hit had PeopleSoft components exposed to the internet that had no business being exposed. In many cases, security teams didn’t even know those endpoints were reachable. They were simply forgotten DNS records pointing at legacy endpoints, a hub that was supposed to be internal but wasn’t, a reverse proxy that was more permissive than anyone remembered.

This is not a “PeopleSoft is old” problem. This is an attack-surface-management problem. An attack surface is something you control, not something the platform inflicts on you.

What this says about “let the vendor own security”

The migration pitch says SaaS makes the patching problem disappear. It doesn’t. It moves it somewhere you can’t see and can’t act on.

The post-mortem on this campaign reads like a competence checklist, not a platform indictment. Mandiant found that the attackers extracted credentials from psappsrv.cfg, mapped connected nodes, and walked the web, app, and batch tiers. This requires AI and a deep familiarity with PeopleSoft architecture, yes, but every one of those moves is something a properly segmented, properly monitored environment makes harder. The organizations that had their app servers walled off from untrusted networks, that watched outbound SMB traffic, that didn’t have PSEMHUB hanging off a public IP, were a far harder target.

Note also what ShinyHunters is known for. This is a group that usually wins through weak authentication, stolen credentials, and cloud misconfigurations, not exotic malware. That profile should be clarifying. The same crew constantly breaches SaaS platforms and cloud services. Moving your HR and finance data into someone else’s tenant doesn’t take you off their menu. It just means that when the next misconfiguration occurs, you find out about it via a breach notification email rather than in your own logs.

The honest framing is this: security is an operational discipline, and operational discipline is exactly the thing you keep when you modernize in place and lose visibility into when you hand the whole stack to a vendor.

The one-person problem this exposed

There’s an uncomfortable staffing truth underneath this incident, and it’s worth saying to the executive who controls the headcount.

A large share of PeopleSoft shops run with one person owning PeopleTools, security configuration, environment management, and patching. On a normal week, that’s a workload problem. During an actively exploited zero-day, when the same person is suddenly responsible for emergency mitigations, log hunting, and exposure assessment against attackers already inside the perimeter, it becomes an incident-response failure waiting to happen.

That risk has nothing to do with whether PeopleSoft is modern. A single-threaded SaaS admin is just as exposed; you’ve simply outsourced the parts they can no longer touch. The lesson isn’t “the platform is fragile.” It’s “we under-resourced a system that runs payroll, finances, and student records, and the bill came due.” This breach is the business case for fixing that.

What the CIO should actually do

Four moves. None of them is “evaluate migration.”

Find out what’s actually exposed — today. The exploit needs network reachability to PSEMHUB and Integration Gateway endpoints. Confirm whether anything PeopleSoft-related answers from outside your trusted network: /PSEMHUB/*, /PSIGW/*, the PIA and app server tiers. Don’t trust the assumption that PeopleSoft is “internal.” Check public DNS records, legacy endpoints, and anything a reverse proxy might be quietly forwarding. Even if you patched, exploitation started May 27. Assume you need to hunt for a prior compromise, not just close the door.

Patch, then verify you weren’t already hit. Oracle released mitigations with the June 10 alert and folded fixes into the June 2026 Critical Security Patch Update. Apply them. Then review web and app server logs for suspicious requests to those endpoints, watch for unexpected outbound SMB connections from PeopleSoft hosts, and look for unfamiliar files or processes. A patch closes the future; it says nothing about the two weeks the door was open.

Treat environment-management infrastructure as a first-class attack surface. What got people wasn’t the application; it was the operational scaffolding around it. Inventory every PeopleSoft endpoint, segment the tiers, put the management hub behind authentication or off the network entirely, and monitor it as it matters. Because it does.

Fund the team, or accept the risk in writing. If one person owns tooling, security, environments, and patching, you do not have an incident-response capability; you have a single point of failure with a pulse. Decide deliberately whether that’s acceptable for a system holding your most sensitive records, and make whoever owns the risk sign off on the answer.

The actual lesson

CVE-2026-35273 is a serious vulnerability, and Oracle’s two-week disclosure gap is a fair reason to be angry. But the organizations that weathered it well and the ones that ended up on a leak site weren’t separated by how old their ERP was. They were separated by whether they knew what they had exposed, whether they segmented it, and whether they had more than one person watching it.

That’s not a migration decision. That’s a management decision. The question was never whether to abandon the platform. It’s whether you’re operating it like it carries the weight it actually carries.

Run the exposure check this week. Not because PeopleSoft is fragile, but because every system that holds payroll and student data deserves to be treated like an asset, and right now, you have a concrete reason to prove yours is.

---

Aaron Engelsrud writes about PeopleSoft modernization, cloud infrastructure, and ERP strategy at peoplesoftcloud.com.