Google and Mandiant have mapped every link in the attack chain for the Oracle PeopleSoft zero day hitting universities and enterprises, and patches are still not available.
With no Oracle patch available for CVE-2026-35273, the question for any organization running PeopleSoft Enterprise PeopleTools 8.61 or 8.62 is no longer whether the flaw is real, but what to do in the weeks between today's out-of-band advisory and a real fix. Google Threat Intelligence Group and Mandiant have now confirmed the exploitation chain, named the actor, and published the indicators of compromise, giving defenders something they can actually act on, according to SecurityWeek's report on the campaign.
CVE-2026-35273 is a critical, unauthenticated remote code execution flaw in Oracle PeopleSoft Enterprise PeopleTools, affecting versions 8.61 and 8.62 and the PeopleSoft Enterprise Applications that depend on them, SecurityWeek reports. Oracle has shipped an out-of-band security alert with mitigations, but patches are not yet available, leaving any internet-reachable instance in the affected versions exposed until a fix lands. The vulnerability sits in software that runs HR, payroll, finance, supply chain, and campus operations for large enterprises and most major universities, which is why the targeting pattern that Google observed is the part that should change how defenders prioritize this week.
The actor is ShinyHunters, which Google tracks as UNC6240. Mandiant and Google Threat Intelligence Group observed activity between May 27 and June 9, 2026, and confirmed the data leaks were published on the ShinyHunters data leak site on June 9. Google notified more than 100 organizations, the majority based in the United States, with roughly 68 percent of them in higher education. ShinyHunters claims to have touched around 300 PeopleSoft instances across approximately 100 organizations. The University of Nottingham in the UK is the first confirmed victim.
The education skew is real, and it is structural. Universities run segmented IT estates, inherit long-lived ERP footprints, and operate on change windows that move on semester calendars rather than vendor patch cycles. That combination turns a critical unauthenticated RCE into a multi-month exposure for many institutions, not because they are negligent, but because their operating reality is misaligned with the cadence of the threat.
What makes the campaign usable for defenders is that the full attacker tradecraft is now public. SecurityWeek, citing GTIG and Mandiant, describes staging environments running customized MeshCentral agents masquerading as legitimate cloud endpoints, the use of administrative command queries inside PeopleSoft, and a lateral-movement and defacement script named [victim_abbreviation]_fanout.sh. The MeshCentral staging is the highest-fidelity hunt target: legitimate remote-management agents deployed through a PeopleSoft RCE, presenting as ordinary cloud workloads, then used as the launch point for the fanout script across the rest of the environment.
The defender playbook for the unpatched window has five concrete moves. First, inventory every internet-facing PeopleSoft Enterprise PeopleTools 8.61 and 8.62 instance, including any test, training, or self-service portals that share the same PeopleTools layer. Second, reduce that surface: place the app and app-server tiers behind a VPN or zero-trust access broker, and shut down any instance that is not business-critical until a patch ships. Third, segment the ERP estate so that a compromise of the app tier cannot reach HR, finance, identity, or backup systems without traversing controlled choke points. Fourth, enforce multifactor authentication and least privilege on every PeopleSoft administrative path, and audit administrative command queries in particular, since the observed campaign relies on them. Fifth, hunt for the indicators: unexpected MeshCentral client binaries and outbound traffic to MeshCentral infrastructure from any PeopleSoft host, the [victim]_fanout.sh filename pattern (and any derivative) on app and app-server hosts, and administrative command queries originating from users or systems that do not normally issue them. Web application firewall and virtual-patch rules for the specific PeopleTools endpoints can buy time, but they are a stopgap, not a substitute for a real fix.
Two pieces of context are worth keeping in view as this story develops. Oracle's choice to ship an out-of-band advisory without a same-cycle patch is a defensible posture only if the mitigations actually close the unauthenticated RCE path; defenders should treat the advisory as a stopgap, apply it carefully, and re-validate exposure after the patch lands. And the ShinyHunters brand has been used loosely by overlapping groups in recent years, so attribution should be read as Google's working label, not as a guarantee that one cohesive team is behind every incident.
The next facts to watch are the patch release, the count of additional confirmed victims, and any new fanout-script variants or MeshCentral infrastructure. Until then, the work is the inventory, the segmentation, and the hunt.