Why the PeopleSoft Victims Were Scanned and Not Chosen

Nobody picked the University of Nottingham.

When the news broke that 454,600 current and former students had their personal and academic records dumped on a leak site, the natural assumption is that someone went after the university. Chose it, studied it, planned the break-in. None of that happened. A criminal group called ShinyHunters was running a scanner across the internet, looking for one specific thing: an Oracle PeopleSoft server that was reachable and vulnerable. The University of Nottingham's server was both. So were more than a hundred other organisations'.

It is the digital version of walking down a street pulling on every car door to see which ones are unlocked. The thief doesn't care whose car it is. They care that it opens.

What actually happened

The flaw is CVE-2026-35273, a remote code execution bug in Oracle PeopleSoft Enterprise PeopleTools. It scores 9.8 out of 10, which is about as bad as these things get, and the reason is simple: it needs no login and no interaction from anyone. Just network access over HTTP to the server. There is no email to click, no password to phish, no person to trick. If the server can be reached, it can be taken.

That combination is what makes it so dangerous, because it is trivial to automate. You don't need a skilled operator carefully working a target. You write a scanner that finds vulnerable PeopleSoft instances, point it at the internet, and let it run. Scan, find, exploit, repeat. ShinyHunters did exactly that, hitting more than 300 instances across over 100 organisations. Around 68% were in higher education, which almost certainly reflects nothing more sinister than universities tending to run PeopleSoft and tending to leave it facing the internet.

The attacks ran from the 27th of May. Oracle didn't publish its advisory until the 10th of June, and CISA only added the bug to its Known Exploited Vulnerabilities catalogue yesterday, on the 12th of June. The exploitation came first.

There was no patch to apply

A lot of the coverage has framed the victims as organisations that fell behind on patching, picking out instances that "had not applied the April Critical Patch Update." That framing is worth correcting, because the records do not support it. The fix for this flaw did not exist in April.

The fix shipped as a dedicated out-of-band patch on the 10th of June, separate from any quarterly update (Oracle Security Alert CVE-2026-35273). The timing matters: the attacks had been running since the 27th of May. The researchers who found the flaw, Trend's Zero Day Initiative, only shipped their own detection for it on the 9th of June (Trend security update 26-025), the day before Oracle's patch. Oracle shipped the fix out-of-band on the 10th of June, after the attacks were already under way, and there is no public evidence that the April update closed the hole. While the breaches were happening, there was nothing to deploy.

So think about what a vulnerability management programme built around CVEs was actually doing between the 27th of May and the 10th of June. It was waiting. There was no CVE number to prioritise, no severity score to sort by, no vendor bulletin to action. Even the tooling that is supposed to get ahead of this had nothing to say: I could not find any vulnerability management vendor that had shipped a detection for the flaw during the attack window, and the data-driven exploit-probability score many teams lean on, EPSS, sat at around 0.025% (Tenable's record for the CVE). A team triaging by that number would have ranked this near the bottom of the queue, on the very days it was being used to empty their databases.

You cannot patch your way out of a threat that arrives before the patch does. And on any given day, the patch backlog is already long: a team that did everything right could still have had no line item for this, because there was no fix to schedule. Patch speed matters, but it only ever answers "what about the bugs with fixes?" The harder question is what protects you on the days when the threat is real and no patch exists yet.

The monster is the pattern, not the bug

It helps to be clear about what you are actually fighting. The real enemy is the pattern CVE-2026-35273 belongs to: cheap, automated, opportunistic scanning that never stops and never sleeps. Kill this particular bug and the scanner simply moves on to the next unauthenticated flaw in the next widely deployed product. It is whack-a-mole, and the moles have been automated.

Once you see the threat that way, the defence changes shape. If you cannot reliably win the race to patch a specific hole, you have to make yourself a worse target for the whole category of attack. Two things follow from that.

The first is to know what you are exposing, and to expose less. The attackers' entire business model depends on finding things that are reachable. A PeopleSoft server that does not need to face the open internet, and doesn't, cannot be found by a scanner trawling the open internet. This is harder than it sounds, because keeping an accurate picture of your own external footprint is genuinely difficult at any real scale. The exercise worth doing is to look at your estate the way the scanner does, from the outside, and ask what an attacker can even see.

The second is to assume the first foothold will eventually happen anyway, and to care about what comes next. In this case the answer was grim. PeopleSoft is where universities keep the crown jewels: student records, HR data, payroll, personal information. The exploit chained several bugs to get there, so the break-in itself was not a single step. But once the attackers had code execution on the server, the valuable data was right there, or a single short hop away. Exposure got them in; proximity to the data is what turned a break-in into a half-million-record breach.

What I take from it

Keep patching, but stop assuming patching is the whole game. There will always be days when the bug is real, the exploitation is live, and the fix does not exist yet. On those days the only thing standing between you and a scanner is how much you have exposed and how far an attacker can travel once they are in.

The University of Nottingham wasn't unlucky in the way we usually mean it. Its server was visible and reachable, on a day when being visible and reachable was enough. The defenders who came through this untouched were not the ones who patched fastest. They were the ones the scanner never found.