Blogs

CVE-2026-35273 and What the PeopleSoft Zero-Day Campaign Means for Higher Education

Between 27 May and 9 June 2026, a cybercrime group called ShinyHunters quietly worked through a list.

They were not guessing. They were not phishing. They had a zero-day vulnerability in Oracle PeopleSoft — a critical flaw in a background component called the Environment Management Hub (PSEMHUB) — and they had automated scripts capable of scanning the internet, identifying every exposed PeopleSoft instance, and compromising it without a single login credential. By the time Oracle published its advisory on 10 June, the attackers had already been inside 300 PeopleSoft environments across more than 100 organisations for two weeks.

The University of Nottingham is the name you have probably seen in the news. 455,000 current and former students. Names, addresses, passport numbers, health data, immigration details, financial records, academic history. Forty gigabytes compressed and exfiltrated. The data is now public on ShinyHunters' leak site. Nottingham declined to pay. The files went up anyway.

Two weeks before Oracle said a word.

The Flaw

CVE-2026-35273 carries a CVSS score of 9.8 — the near-maximum on a scale that measures how bad a vulnerability is. The score reflects four facts that compound each other:

No authentication required. The attacker does not need a username or password. They need only a network path to the PeopleSoft web server.

No user interaction required. Nobody has to click a link, open an attachment, or do anything at all. The server processes the request and the exploit runs.

Remotely exploitable. Any PeopleSoft instance with PSEMHUB reachable over the internet is a valid target. Geography is irrelevant.

Full system takeover. Successful exploitation gives the attacker arbitrary code execution on the server — the equivalent of sitting at the keyboard with administrator access.

The vulnerability lives in PSEMHUB — the Environment Management Hub. This component exists entirely to support PeopleSoft's patching infrastructure. It runs quietly in the background, deployed by default on every PIA web server installation, accessible under the path /PSEMHUB/hub. Most PeopleSoft administrators have never looked at it. It does nothing during normal operations.

It was that quiet component that became the door.

How the Attack Actually Worked

ShinyHunters did not improvise this. The campaign's technical architecture — documented by Google's Threat Intelligence Group and Mandiant — reflects months of preparation.

Stage 1: Infrastructure. On 27 May at 22:14 UTC, the attackers stood up a MeshCentral remote management server and provisioned Let's Encrypt SSL certificates for a command-and-control domain they named azurenetfiles.net — designed to blend into network traffic as Azure NetApp Files infrastructure. They were not in a hurry.

Stage 2: Scanning at scale. Automated scripts swept the internet for PeopleSoft instances with PSEMHUB endpoints responding on HTTP and HTTPS. Every responding server was catalogued.

Stage 3: Exploitation. The exploit is a gadget chain — a sequence linking CVE-2026-35273 with older known vulnerabilities in Oracle PeopleSoft, producing an attack that neither component enables independently. The chain terminates in Java's XMLDecoder processing a crafted payload, which deserialises malicious objects and executes system commands on the server. A single unauthenticated HTTP POST to /PSEMHUB/hub. That is the entire entry.

Stage 4: Credential harvesting. Inside the system, the attackers went directly to psappsrv.cfg — PeopleSoft's application server configuration file, which contains database credentials, integration node passwords, and environment topology. They knew exactly where to look.

Stage 5: Lateral movement. A script named [victim]_fanout.sh was deployed to /tmp. It read /etc/hosts to enumerate internal hostnames, then ran a credential spray over SSH against every identified host. A marker file — README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT — was dropped into PeopleSoft directories.

Stage 6: Exfiltration. Data compressed with zstd. Transferred outbound over SSH to the ShinyHunters leak server. For Nottingham, that was 40 GB.

Stage 7: Extortion. Contact. Ransom demand. Deadline. Leak.

One detail stands out beyond the technical mechanics: the attackers operated entirely within PeopleSoft's application logic — using PeopleSoft's own APIs to navigate and extract records. Standard database monitors saw normal application traffic. SIEMs saw nothing unusual. The intrusion was invisible until the data appeared on the leak site.

This Is Not a PeopleSoft Problem

That is worth saying plainly, because the immediate instinct after a campaign like this is to question the platform.

PeopleSoft is not the problem. The vulnerable component — PSEMHUB — is a patching utility that has no role in day-to-day operations. The student portal, academic records, financial transactions, HR functions, and every business process that PeopleSoft runs were not compromised through the application itself. The door that was kicked in was a service entrance that should have been locked independently of the main building.

Oracle's own advisory confirms: disabling PSEMHUB "has no impact on the day to day operation or functionality of the PeopleSoft System."

The issue is not the platform. The issue is the assumption — present in every default PeopleSoft installation — that a component deployed automatically is a component that should remain running indefinitely. PSEMHUB is needed for perhaps a few hours when a system administrator runs Change Assistant to apply patches. It ran continuously, exposed to the internet, for years on most of the systems that were compromised.

Default configurations are not secure configurations. They are starting points.

The AI Dimension

This campaign is being discussed primarily as a PeopleSoft story. It is more accurately read as an AI-automation story with PeopleSoft as the target.

The scale — 300 instances, 100+ organisations, 13 days — is not achievable through manual exploitation. The automated reconnaissance, credential mapping, lateral movement scripts, and exfiltration pipeline reflect a level of operational sophistication that compress what would once have taken weeks of manual work into hours of scripted execution. Mandiant's investigation confirmed automated reconnaissance against configuration files, server mappings, and internal network infrastructure — running across victim environments simultaneously.

The industry has begun naming this shift explicitly. Pathlock's Chief Strategy Officer, commenting on this campaign, described it as "the new kind of attacks every ERP will face in today's new agentic world." That framing is correct. The barriers to industrialised exploitation — skill, time, human bandwidth — are collapsing. AI-assisted tooling does not make every attacker a nation-state actor, but it removes the constraints that once kept large-scale campaigns rare.

The implication for higher education institutions is not subtle: the organisations that were compromised in this campaign were not negligent. Many of them had standard security controls in place. They simply did not know that PSEMHUB was running, did not know it was exploitable, and did not have the monitoring in place to detect reconnaissance activity before it became exfiltration.

The window between vulnerability disclosure and active exploitation — once measured in months — no longer exists. This campaign began two weeks before Oracle published a word.

What Institutions Running PeopleSoft Should Do Now

Oracle has published an official out-of-band mitigation for CVE-2026-35273. The fix is not a patch — it is the removal of PSEMHUB from the WebLogic deployment. Oracle's guidance for Single Server configurations:

1. Stop the PIA domain
2. Remove the PSEMHUB module entry from application.xml
3. Remove the PSEMHUB.war folder from the deployment directory
4. Restart the PIA domain

This eliminates the attack surface entirely. PSEMHUB can be re-enabled when actively needed for patching, then disabled again. Oracle has confirmed that the removal has no impact on normal PeopleSoft operations.

If you are on PeopleTools 8.61 or 8.62: Apply Oracle's CPU187 mitigations immediately. They are available through My Oracle Support.

If you are on an earlier PeopleTools version: No patch is available. The mitigation — removing PSEMHUB — is your only option. Treat it as urgent.

Regardless of version: Check your access logs for hits to /PSEMHUB/hub covering the period 27 May to 12 June 2026. If HTTP access logging was not enabled, review your firewall logs for inbound traffic to the PeopleSoft web port from unexpected sources. If you find anomalous activity, treat it as a confirmed compromise and engage incident response.

Check for persistence indicators. Google GTIG published specific forensic markers from this campaign:

• Unexpected folders named logs, persistantstorage, or scratchpad under PSEMHUB directories
• Recently created or modified .xml files under envmetadata/data/environment/
• Unexpected .jsp files under the PSEMHUB.war directory
• Outbound SMB traffic on port 445 from PeopleSoft hosts to external IPs

Known attacker IPs to check against your logs: 142.11.200[.]186–190, 108.174.202[.]99, 176.120.22[.]24

One standing operational note: Oracle has confirmed that any new web server deployment or PeopleTools upgrade will redeploy PSEMHUB automatically. The removal procedure must be repeated as part of every new web server build or upgrade activity until Oracle ships a permanent fix.

The Longer View

ShinyHunters did not choose PeopleSoft arbitrarily. They chose it because it is deeply embedded in university operations, holds dense concentrations of sensitive personal data, and — historically — has not been treated as a security-critical internet-facing surface. Universities are research institutions, not security operations centres. The gap between how PeopleSoft is used and how it is secured is wide, and it has been wide for a long time.

This campaign closes that gap by force. Whether institutions respond by hardening what they have, accelerating their PeopleTools upgrade cycles, or implementing continuous vulnerability monitoring — the calculus has changed.

The University of Nottingham had 455,000 records on a leak site before Oracle published its advisory. The next campaign will not wait for a CVE either.

The institutions that come through the next one will be the ones that stopped treating their ERP infrastructure as a back-office system and started treating it as the target it has always been.

References: Oracle Security Alert CVE-2026-35273 | Google Cloud / Mandiant Threat Intelligence Report | NVD CVE-2026-35273 (Published 11 June 2026) | Cybersecurity Dive | SecurityWeek | Help Net Security | Pathlock Security Blog | Computer Weekly