One Oracle Zero-Day, 100+ Breaches: Inside the ShinyHunters PeopleSoft Campaign

A single unauthenticated bug in a two-decade-old HR and finance platform has now produced breach notifications from a carmaker, a farm equipment manufacturer, an insurance regulator, and an entire wave of universities. That’s the practical shape of CVE-2026-35273: not a headline about one company, but a case study in what happens when a critical flaw in widely deployed enterprise software sits unpatched during a window when a professional extortion group is already scanning for it.

What the vulnerability actually is

CVE-2026-35273 lives in the Updates Environment Management component of Oracle PeopleTools, the framework underneath PeopleSoft HR, finance, and campus-management applications. It’s rated CVSS 9.8, about as bad as a score gets, because the attack requires no authentication and no user interaction: send the right request to an exposed PeopleSoft instance running PeopleTools 8.61 or 8.62, and you get remote code execution.

That combination, unauthenticated plus remote plus code execution, is the profile that turns a vulnerability into a mass-exploitation event rather than a targeted one. Attackers don’t need to phish anyone or steal credentials first. They need a list of internet-facing PeopleSoft instances, which is the kind of thing a port scan finds in an afternoon.

The timeline that matters

ShinyHunters, the group behind this campaign, exploited the flaw as a genuine zero-day, meaning before Oracle had a patch available, from roughly May 27 to June 9, 2026. Oracle shipped an emergency fix on June 10. Two weeks doesn’t sound like much, but against an unauthenticated RCE with no login required, it’s more than enough time to compromise every reachable instance an attacker can find and start exfiltrating data quietly, well before anyone notices.

That’s exactly what happened. Breach notifications didn’t start trickling out in June when the patch shipped. They arrived in a cluster starting July 3, nearly a month later, as affected organizations finished their forensic investigations and legal review. Nissan disclosed exposure of employee data including Social Security numbers, national identification numbers, and financial and tax records. Kubota North America and Aflac’s Japan subsidiary confirmed data theft around the same date. The National Association of Insurance Commissioners said the stolen data was largely public-facing material, outdated logs, and configuration files, a smaller blast radius but the same root cause. Google’s threat intelligence team separately documented the same actor hitting universities running PeopleSoft for student and staff records. Researchers now estimate more than 100 organizations were touched by this single flaw.

Organization	Disclosed	Data exposed
Nissan	July 3, 2026	SSNs, national ID numbers, financial/tax records
Kubota North America	~July 3, 2026	Employee data (details limited)
Aflac (Japan subsidiary)	~July 3, 2026	Customer/policy data (details limited)
NAIC	July 2026	Public-facing data, outdated logs, configs
Multiple universities	Ongoing	Student and staff records

Why this keeps happening to PeopleSoft specifically

PeopleSoft isn’t a niche product. It’s the kind of enterprise system that gets deployed once, heavily customized, and then left running for fifteen years because migrating off it is its own multi-year project. That longevity is exactly what makes it an attractive target: large, stable install base, frequently internet-facing for self-service HR and student portals, and patch cycles that in practice lag well behind the vendor’s release schedule because upgrading touches so much custom code.

This isn’t the first time this exact pattern has played out with Oracle enterprise software; ShinyHunters and adjacent groups have run near-identical campaigns against other widely deployed platforms, and the group’s track record includes the 2024-2025 Snowflake credential-theft wave and breaches touching Ticketmaster, AT&T, and Salesforce customer environments. This is a group with an established playbook: find a critical flaw in something enterprises can’t quickly replace, exploit broadly, exfiltrate quietly, then monetize through extortion, sometimes months after the initial breach.

What patching alone doesn’t fix

The uncomfortable part of this timeline is that “we’re patched” and “we’re safe” are different claims here. If your organization ran an internet-facing PeopleTools 8.61 or 8.62 instance at any point between May 27 and June 9, 2026, applying the June 10 patch stops future exploitation of this specific flaw. It does not retroactively determine whether you were one of the instances hit during that window.

The organizations now issuing breach notifications aren’t doing so because they got newly compromised in July. They’re doing so because their forensic review of that May-June window turned up evidence of prior compromise. If you haven’t done that review, patching status alone isn’t a clean bill of health.

What to actually do this week

1. Confirm your PeopleTools patch level, not just that you applied “a” patch, but that you’re specifically past the fix for CVE-2026-35273 for the Updates Environment Management component.
2. Pull logs from May 27 through June 9, 2026 for that component specifically, and look for anomalous requests, unexpected process spawns, or outbound connections that don’t match normal PeopleSoft behavior.
3. If your log retention doesn’t cover that window, don’t assume you’re clean. Treat the gap as a reason to escalate, since the absence of evidence isn’t evidence of absence when the retention window itself is the problem.
4. Check whether your instance was ever directly internet-facing, even briefly, since that’s the exposure path this exploit requires. An instance behind VPN-only access for its entire history has a fundamentally different risk profile than one with a public login page.

If your team is running legacy enterprise platforms like PeopleSoft alongside newer infrastructure, this kind of gap, patch discipline that lags the actual threat timeline, is usually a symptom of a broader security posture review being overdue, not a one-off miss. A single unpatched zero-day window did more damage here than most companies’ entire annual vulnerability backlog. That’s the actual lesson, independent of which vendor’s product it happened to be this time.