Let’s not sugarcoat it: the breach at the University of Nottingham wasn’t just a simple break-in; it was a structural collapse of cybersecurity hygiene in Higher Ed. When an extortion group—specifically UNC6240, the heavy hitters behind the ShinyHunters banner—walks through the front door of your student records system and walks out with the personal details of 454,600 people, it’s not an accident. It’s a systemic design failure.
We’re talking about names, home addresses, phone numbers, passport numbers, even disabilities—the kind of PII that lives forever on dark web leak sites. It’s damning. The university was working with a third party to manage the platform, and that, right there, is where the story usually starts to fall apart. You can have the best policies in the world, but if your vendor management lacks accountability for the underlying architecture, the policies are just expensive paperweights.
The University of Nottingham isn’t the only victim, and they won’t be the last. This incident is just a symptom of a broader, more dangerous trend: the relentless exploitation of aging, sprawling enterprise software architectures that IT departments can barely keep track of, let alone patch effectively. Let’s break down exactly what went wrong.
Deconstructing CVE-2026-35273: The PeopleSoft Problem
The weapon here wasn't some sophisticated AI-driven hack that cracked a 256-bit encryption key. No, it was simpler. It was CVE-2026-35273, a remote code execution (RCE) flaw in Oracle PeopleSoft Enterprise PeopleTools—specifically the Environment Management Hub (PSEMHUB).
With a CVSS score of 9.8, this isn't a vulnerability; it's an open window into the enterprise. It allows for unauthenticated RCE via simple HTTP POST requests. No user interaction, no phishing, no trickery required. Just an attacker pointing an automated script at your PSEMHUB endpoint, sending a malformed request, and—poof—they're executing code as the application user.
In a university setting, PeopleSoft is often the "black box." It’s monolithic, it’s complex, and it’s usually managed by teams that are stretched impossibly thin. When you have a zero-day—used by ShinyHunters between May 27 and June 9, 2026—your defensive capabilities are effectively neutralized unless you have real-time visibility into your perimeter traffic. If you weren’t actively monitoring those /PSEMHUB/* endpoints for suspicious POST activity, you were already behind. It's a sobering reminder of the gap between having security measures and enforcing them, a crisis we’ve discussed before in AI Accelerates Vulnerability Discovery: Record 206 CVEs on Patch Tuesday Signal New Normal. For a detailed technical breakdown of this vulnerability, see our analysis: Critical Exploited Zero-Day Found in Oracle PeopleSoft Applications. Modern exploitation moves faster than traditional patch cycles, and that’s a reality IT leaders haven't fully absorbed.
UNC6240: Who Are They and Why Do They Keep Winning?
Google’s Mandiant unit has linked this campaign to UNC6240, a group that’s clearly learned how to play the game. They aren't just hacking to hack; they’re building industrial-scale data theft operations. Their TTPs (Tactics, Techniques, and Procedures) are textbook extortionist-level efficiency.
Once inside, they weren't just sniffing traffic. They deployed custom MeshCentral agents—masked as legitimate Azure service binaries—communicating back to azurenetfiles.net to maintain a persistent C2 channel. They were methodical, conducting recon by mapping configurations inside psappsrv.cfg and config.xml, finding exactly where the juice was hidden.
And the lateral movement? Highly automated. Their custom [victim]_fanout.sh script handled credential spraying across internal subnets, systematically compromising everything in its path, all while dropping a charming extortion marker: README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT. It’s audacious, it’s arrogant, and it’s effective.
The stolen data wasn’t just sitting there, either. It was compressed with zstd and exfiltrated straight to their Data Leak Site (DLS) hosting servers, turning the university’s reputation into a bargaining chip in an extortion game they were already losing. This isn't just about stealing data; it's about weaponizing it to force payment, which is exactly why CISO Resilience in the AI Era: Harder Work, Higher Demand is such a prevalent topic right now. The pressure on CISOs to manage both the infrastructure and the extortion fallout has reached a breaking point.
The Higher Education Bottleneck
Why was Nottingham—and 68% of the victims alert-flagged by Mandiant—the primary target? It’s not a mystery. Higher ed is the perfect, low-resistance target. They have high-value, highly sensitive personal and financial data—everything from student bank details to passport information—and they operate on legacy ERP architectures that haven’t seen a proper security posture update in a decade.
Universities have a unique challenge, too. They have a massive, transient population of users, and their IT infrastructure often needs to be open and accessible, making a 'zero trust' model difficult to sell to stakeholders who value convenience—and lack of friction—over a locked-down, secure environment.
When you pair legacy software, limited security budgets, and a philosophy that prioritizes open access and research throughput over granular access controls, you're not just creating a risk; you're inviting it. UNC6240 didn't target Nottingham by accident; they targeted them because they knew the architecture would likely be the most vulnerable point in the organization. The vulnerability in the PeopleSoft environment was just the mechanism; the weak link was the architectural assumption that the perimeter was secure. It’s hard to blame the IT team when their budget priorities often look backward at systems that refuse to be retired, yet still, the responsibility remains to protect the data that thousands trust them to hold. It's a systemic problem in the industry, and it demands systemic change.
Lessons in Defensive Resilience
If you’re still running PeopleSoft instances anywhere in your perimeter, stop reading this and go audit your EMHub configuration immediately. If you're using it in a multi-server setup, disable it. If a single-server setup, remove the PSEMHUB application entirely.
But that’s not enough. You need to be blocking external perimeter access to /PSEMHUB/* and /PSIGW/HttpListeningConnector globally. If you need these endpoints exposed, you’re exposing yourself to everything an attacker can find, and you're doing so at the speed they can automate the exploitation.
Beyond that, you need to be actively hunting. Check your PIA WebLogic access logs for external POST requests to these endpoints. It’s the easiest signal of compromise you’ll find. And scan your own filesystem, specifically inside PSEMHUB.war, for surprise .jsp files or modified .xml files. If you find them, assume you’re already breached and begin your incident response.
The bottom line is simple: stop relying on the software vendor to tell you what's secure and start assuming that everything you deploy is a liability until you have evidence to the contrary. Security isn't a state you reach; it's a constant, punishing, and unending process of re-evaluation. If you aren't testing your own rules and defenses—like the breach and attack simulation strategies we see successful organizations taking—you’re essentially just waiting for the next UNC6240 agent to tell you what your data was worth. And that’s a lesson nobody wants to learn the hard way.