PeopleSoft, ShinyHunters, and the Exposure Beyond the Campaign
A public-service warning on the ShinyHunters PeopleSoft campaign (CVE-2026-35273). The campaign is one plane of risk; credential exposure is another — and for at least 2,604 organizations it was already there.
A zero-day made the headlines. The exposure underneath it was already there — and most of the organizations carrying it were never told.
In early June 2026, Oracle shipped an emergency, out-of-band patch for PeopleSoft. For roughly two weeks beforehand, a financially motivated group known as ShinyHunters had been quietly exploiting a critical flaw in the platform’s management interface — no password required — to reach the systems behind it. The coverage that followed did what coverage does: it counted named victims. A university. An automaker. Roughly a hundred organizations put on notice.
An incident, though, is not the same thing as exposure. Setting the campaign aside entirely, we asked a narrower and more durable question: how many organizations are already reachable through their PeopleSoft front door, simply because working credentials to it are circulating in the criminal ecosystem? Using only externally observable data — nothing touched, no system accessed — the answer is at least 2,604 organizations, worldwide.
These are two different planes of risk, and the distinction is the whole point. One is an event: a specific vulnerability, exploited over a specific fortnight, now closed by a patch. The other is a condition: credentials to live portals, copied by infostealer malware from the machines of employees, contractors, students and applicants, and passed around for months before the campaign began — and still valid the day after the patch landed. We measured the condition. The campaign happened to run alongside it. Patching closes the event; it does nothing to the condition, because you cannot patch a password that has already been copied.
For a business leader or a board, this is not cause for alarm. The exposure is broad, but the remedy is unusually cheap and fast — this is one of the few security problems whose highest-leverage fixes (patch the platform, rotate the credentials, turn on multi-factor authentication) can be executed in a week, without a project or a budget cycle. The right question in the next leadership meeting is simply: do we run internet-facing PeopleSoft, and have we done those three things?
For a security leader, the useful line is between who was notified and who is exposed. The organizations contacted during the campaign are the visible tip; the exposed population is more than an order of magnitude larger, and largely unaware it belongs to the set. And the figure is deliberately conservative — a deduplicated count of distinct organizations, a floor with an unread tail, not a closed census or a victim tally.
This is a public-service warning, and it asks for nothing. What follows is mostly charts: the fix first, then the two populations and why they must never be conflated, the size of the gap between them, how we counted and what the number does and does not claim, the two clocks that separate the campaign from the exposure, and where in a real portfolio the risk tends to concentrate. If you run PeopleSoft, the checklist in the next section is the entire reason we wrote this.
If you run PeopleSoft, this is the week
The actions come first, because they are the point. None of them depend on the counts that follow — the counts are only why we’re raising a hand.
Patch CVE-2026-35273
Apply CPU187 / the June 2026 Critical Security Patch Update. Necessary — not sufficient. It closes the remote-code path; it does nothing to a password already copied.
Rotate every PeopleSoft portal credential now
The patch does not invalidate a credential that has already been captured. Rotate across every internet-facing portal, regardless of account type.
Enforce MFA / put federated SSO in front of PeopleSoft
The single highest-leverage move. In our own data, deployments fronted by federated SSO and MFA exposed materially less to infostealers (see Section 06).
Lock down the management plane
The exploited interfaces — /PSEMHUB/hub and /PSIGW/HttpListeningConnector — are unauthenticated, and are not the login page. Disable EMHub / remove PSEMHUB where you can, or block it at the perimeter.
Assume lateral reuse
In flat-identity environments a single credential — even “just a student” or an applicant login — can travel well past the portal it was captured on. Rotate anyway; don’t triage by account type.
Hunt for prior compromise
Exploitation predated the patch, so a clean patch is not a clean box. Check config-export log events, unexpected admin accounts, and the README-IF-YOU-SEE-THIS marker file.
Two populations, one platform — never conflate them
Everything downstream depends on this distinction. Two different groups, reached two different ways — and conflating them would be a serious error.
Not breached by this campaign. Exposed to the class of attack it represents.
They are related by precondition, not by breach. A scanner counted Path A. Our measurement found Path B — and it is larger. Patching the CVE closes the remote-code route; it leaves a copied credential exactly where it was. This is not a breach count and not a victim list: it is 2,604 organizations running the targeted platform with credentials already in circulation.
The notified victims are the visible tip
Roughly 100 organizations were notified. At least 2,604 sit in the precondition — more than an order of magnitude the coverage never touched.
~100 notified vs at least 2,604 exposed
How we counted — and what it does not claim
How we arrived at the figure — and what it does and doesn’t support. We publish the smaller, defensible number rather than a larger, shakier one.
- We drew on a corpus of credentials harvested by infostealer malware from infected machines worldwide.
- We matched captured login URLs carrying PeopleSoft’s Internet Architecture path signatures —
/psp/and/psc/— anchored to the portal host so a substring can’t create a false positive. - We collapsed everything to the registrable organization domain, so each organization is counted once no matter how many captures it appears in.
- We publish the distinct organization only — never raw record counts, which are inflated by re-capture and re-distribution and don’t correspond to real organizations.
At least 2,604 distinct organizations running internet-facing PeopleSoft, for which working portal credentials are already in circulation.
- A precondition, not an outcome — an exposed platform plus a key already copied.
- A deduplicated floor — distinct organizations, counted once, with an unread tail.
It is not a breach count, and not a claim about the internal state of any organization’s systems.
- Not 2,604 confirmed breaches, and not a roster of campaign victims.
- Not proof of a vulnerable version, or a reachable management plane, on any given host.
The token /EMPLOYEE/ in a URL is PeopleSoft’s default portal-registry name — it appears on external applicant portals too, and is not proof of an internal staff account. Internal-versus-external comes only from account-type classification, never from the URL string.
A conservative floor. 2,604 counts distinct organizations, each once; many of them show multiple exposed modules over long capture windows. It is a floor with an unread tail — “at least 2,604” — not a closed census.
The campaign is the weather. The exposure is the climate.
One discrete event, external and now patched. One standing condition — the thing we measured — present before the CVE and outliving the fix.
Two planes of risk on one timeline
From applicant to payroll — and the surprise in between
The credentials are not one kind of thing — and which kind dominated is where our own expectations were wrong.
Two things stood out when we looked by hand. The PeopleSoft path signatures turned up almost everywhere we checked. The second ran against our own expectation: going in, prior experience pointed to the usual shape — heavily external, with consumer and third-party logins outnumbering internal ones by a wide margin. What we found was a great deal more internal credential exposure than that predicted — employee and HR self-service logins, the accounts that lead to payroll and personal records. We won’t put a number on it: this is a direction, not a rate. But it disproved our own prior, and internal exposure is the part that should worry a defender.
What we expected vs what we found
Where federated SSO (ADFS) and MFA fronted PeopleSoft, that internal exposure didn’t surface the same way — the federation layer stood in front of the portal, and only it appeared in the corpus. Moving authentication off local PeopleSoft passwords and behind SSO with MFA is what put a deployment out of easy reach here. It’s the highest-leverage control, and its effect shows up in the data itself.
The zero-day was the hard way in. For at least 2,604 organizations the easy way — a working password already in circulation — was open the whole time, and it stayed open the day after the patch shipped. A patch closes the vulnerability; it does nothing to a credential that has already been copied.
If you run internet-facing PeopleSoft, do three things this week: apply CVE-2026-35273 (CPU187), rotate every portal credential regardless of account type, and put federated SSO with MFA in front of the login. None of it needs a project or a budget cycle — and in our own data, the deployments already fronted by SSO and MFA were the ones this exposure could not reach. That is the whole message: patch, rotate, enable MFA. This analysis asks for nothing else.