A single Oracle PeopleSoft zero-day let the ShinyHunters group breach more than 100 organisations, from the University of Nottingham to Nissan. The lesson for third-party risk teams is concentration risk: shared vendor software turns one flaw into many incidents at once.
Payroll software is supposed to be boring. In mid-2026, one such system became the way into more than 100 organisations at the same time. Attackers exploited a single zero-day in Oracle PeopleSoft, the platform that runs payroll, tax and personnel records for thousands of large employers, and used it to steal data from victims as different as the University of Nottingham, the carmaker Nissan and the United States National Association of Insurance Commissioners (NAIC). No single security team was beaten in isolation. They shared one dependency, and the flaw sat in the dependency. That is concentration risk, and it is why this is one third-party story rather than a hundred separate breaches.
What happened
The flaw, tracked as CVE-2026-35273, sits in Oracle PeopleSoft PeopleTools, the framework layer common to PeopleSoft deployments. Google's Mandiant confirmed it was exploited as a zero-day, which means the attacks ran before any fix existed, and dated the activity it observed to between 27 May and 9 June 2026. Only afterwards did Oracle disclose the vulnerability and release emergency mitigations. In that window the extortion group ShinyHunters worked at scale. It told BleepingComputer it had reached more than 300 PeopleSoft instances across roughly 100 organizations, targeting both cloud-hosted and on-premises systems, and Mandiant said it notified more than 100 affected bodies.
The downstream list keeps growing. In filings with the California Attorney General, Oracle told customers that the personnel records of hundreds of companies may have been taken. Nissan, which runs employee payroll and tax data on PeopleSoft, said current and former staff in the United States, Canada, Mexico and Brazil were affected. The University of Nottingham breach touches more than 450,000 students, according to BleepingComputer. NAIC, which detected unauthorised access on 11 June 2026, says the stolen material was mostly public filings, outdated logs and configuration files, and disputes the attacker's wider claims. Most of the victims were in the education sector, which relies heavily on PeopleSoft for student and staff systems.
Why it matters for third-party risk
Strip away the names and the pattern is plain. Thousands of organisations, and many of their suppliers, run the same product from the same vendor. A vulnerability in that product is not one company's problem. It is a correlated failure across everyone who runs it, set off on the vendor's schedule rather than yours.
Vendor registers rarely capture this. Oracle shows up as a single row, tagged as a payroll or HR provider. What the row does not show is how many critical processes ride on PeopleSoft inside your own walls, how many of your suppliers run it too, and how quickly Oracle can ship a fix when a zero-day lands. For firms in scope of the EU Digital Operational Resilience Act (DORA) or the NIS2 directive, that blind spot is now a supervisory matter as well as a security one, since both regimes ask organisations to understand ICT concentration and their fourth-party dependencies. This incident is a clean example of the risk those rules are aimed at.
What teams should take from it
Three moves are worth making now. First, map shared platforms: tag which internal systems and which suppliers depend on the same core software, especially ERP, HR and identity, so you can estimate a blast radius the moment an advisory appears rather than days later. Second, treat vendor patch speed as a measured control. Know in advance how each critical supplier discloses and remediates a zero-day, because that response time sets the size of your exposure window. Third, rehearse the shared-platform scenario in a tabletop exercise: a core vendor has an unpatched, actively exploited flaw, and the team has to decide who is accountable, what can be isolated, and what to tell staff whose payroll data is at risk.
For third-party risk teams, this is where continuous vendor monitoring proves more useful than a once-a-year questionnaire, because the risk here changed in days, not quarters.
FAQ
What is CVE-2026-35273?
It is a zero-day vulnerability in Oracle PeopleSoft PeopleTools, the framework shared across PeopleSoft deployments. Mandiant says it was exploited between 27 May and 9 June 2026, before a patch existed. Oracle has since disclosed the flaw and issued emergency mitigations.
Why is this a third-party incident and not a normal breach?
Because the victims were compromised through a shared piece of vendor software, not through their own bespoke systems. One provider's flaw exposed many downstream customers at the same time, which is the defining feature of software supply-chain and ICT concentration risk.
What should organisations running PeopleSoft do now?
Apply Oracle's mitigations and updates for CVE-2026-35273, hunt for signs of unauthorised access dating back to late May 2026, and map which business processes and suppliers depend on the platform so the potential impact is clear.
Want this applied to your supplier ecosystem? See the platform in action and map your top vendor risks live in one walkthrough.
