Oracle’s 13-Day Silent Window Is the Real Story Behind the PeopleSoft Breach

109

The Uncomfortable Question

When ShinyHunters began exploiting Oracle PeopleSoft on 27 May 2026, it was not inevitable that 100 organisations would be breached before a single word of warning appeared. That outcome was shaped, in part, by a vendor disclosure process that left every internet-facing PeopleSoft server without official guidance for 13 days while attackers were actively inside victims’ networks.

The vulnerability itself — CVE-2026-35273, a CVSS 9.8 unauthenticated remote code execution flaw — is serious by any standard. No credentials, no user interaction: just network access to the server. When attackers weaponise a flaw like this before any advisory exists, defenders are entirely reliant on their own detection and network controls. Most organisations do not have those in place for components they have no reason to consider high-risk.

What Happened in Those 13 Days

Google’s Mandiant team documented the campaign in detail. At 22:14 UTC on 27 May, attackers had already installed a remote access agent inside a victim’s PeopleSoft environment. Within 11 minutes they had automated SSL certificate management. By 29 May they were checking for code-signing tools — a sign they were preparing for persistent, long-term access.

The campaign ran uninterrupted for 13 days. Oracle published its advisory on 10 June, one day after ShinyHunters had already gone public with the stolen data. By then, more than 100 organisations had been compromised across 300 PeopleSoft instances. The University of Nottingham lost 40 GB of data covering nearly 455,000 people, including passport numbers, ethnicity and disability records, per The Hacker News. That data cannot be recalled once published.

The Structural Problem With Enterprise Vendor Disclosure

Oracle’s standard approach is a quarterly Critical Patch Update cycle, with provision for out-of-band advisories in serious cases. In this instance, an out-of-band advisory was issued — but only after the data was already being auctioned on ShinyHunters’ leak site. The Register reported that Oracle had not confirmed whether a complete patch was even available, and that detailed remediation documentation remained behind a support login rather than in publicly accessible guidance.

This is a recognisable pattern in enterprise software. Vendors balance disclosure speed against the risk that early public notice helps more attackers than it helps defenders. That logic had some merit in an earlier era. It is much harder to sustain when criminal groups are operating at scale, running automated campaigns against known vulnerabilities across hundreds of instances simultaneously.

There is a reasonable case that when evidence of active, widespread exploitation already exists, the calculation should shift. A brief, vague advisory on day one — “we are aware of active attacks against PSEMHUB endpoints; restrict external access while we investigate” — would have been actionable for defenders without materially helping attackers who were already operational. The 13-day silence served no protective purpose.

What This Means for Your Organisation

The lesson here is not simply “patch faster.” You cannot patch a zero-day before an advisory exists. The lesson is about reducing what attackers can do during the inevitable gap between exploitation and disclosure.

The PSEMHUB component at the centre of this attack is an environment management tool, not a customer-facing service. Its internet exposure was, in most cases, a configuration default rather than a deliberate choice. An attacker who cannot reach the endpoint cannot exploit the vulnerability — regardless of whether a patch exists.

The practical response, for any organisation running PeopleSoft or comparable enterprise software, starts with these steps.

• Apply CPU187 mitigations immediately. Disable or remove the PSEMHUB service, and block /PSEMHUB/* and /PSIGW/HttpListeningConnector at your perimeter, per Oracle’s guidance. This closes the entry point.
• Audit your internet-facing attack surface. Which components of your enterprise applications are reachable from the internet? Most should not be. Move admin and management interfaces behind a VPN, or restrict access to known IP ranges. This costs almost nothing and eliminates a broad class of exposure.
• Build detection alongside prevention. Monitoring for POST requests to admin endpoints, unexpected outbound connections, and new executables in application directories would have surfaced this campaign within hours of initial compromise — before significant data left the building. That capability cannot be improvised during an active incident.
• Subscribe to vendor security alerts. Oracle’s CPU advisories go to registered customers. Being on that list, and having a process to act on out-of-band alerts within hours rather than days, is table stakes for any organisation running enterprise software at this level.

The Bigger Picture

ShinyHunters are not a sophisticated state-sponsored actor. They are a financially motivated criminal group using off-the-shelf remote access tools, hardcoded credentials, and file compression utilities. The damage they caused in 13 days across more than 100 organisations reflects the gap between how enterprise software is typically deployed and the speed with which an attacker can move through it once they have a foothold.

Closing that gap requires better network architecture, better outbound monitoring, and vendors who treat evidence of active exploitation as a reason to communicate earlier rather than later. All three are achievable. The 13-day window was not inevitable — but it will happen again unless the default changes.