PeopleSoft 0-Day Bleeds Universities as ShinyHunters Cashes In

Anyone who has run an HR or student information system knows PeopleSoft sits in the worst possible spot: deep enough in the stack to hold every sensitive record, old enough that nobody on the current team wrote the integration. That's the system ShinyHunters spent the back half of May quietly looting. By the time Oracle put a name to the bug, the data leak site was already filling up.

What Happened

The vulnerability is CVE-2026-35273, a server-side request forgery in Oracle's PeopleSoft suite rated 9.8 out of 10. As Ars Technica reported, ShinyHunters had been exploiting it since May 27, more than two weeks before Oracle flagged the issue. Oracle has shipped a stopgap mitigation but has not fully patched the flaw. The bug is remotely exploitable, which is the worst combination of words you can read in a Tuesday morning advisory.

Google's Mandiant team identified and analyzed the activity. As of Wednesday, the group had hit roughly 300 endpoints across about 100 organizations. Around 68 percent of those victims operate in higher education. The University of Nottingham confirmed it was breached and that a "significant" amount of student data ended up with the attackers. ShinyHunters then published gigabytes of claimed Nottingham data on its leak site to apply pressure.

At least one customer has been extorted to keep stolen data offline, and Google has confirmed victims are receiving demands. On Tuesday, a researcher noted the group had exposed directories revealing ongoing PeopleSoft targeting, and even left a staging server with their tooling accessible. That is how Mandiant got such a clean view of the attack chain. The DLS claimed 48GB of data recovered from a single victim, which is not a one-table dump. That is months of records, attachments, and probably backups.

ShinyHunters has been around since at least 2019. Past victims include Ticketmaster via the Snowflake breach, Santander, and Salesforce (and through Salesforce, Google and reportedly many others). This is not a new actor learning the trade. This is a mature operation with a working revenue model.

Technical Anatomy

SSRF is the quiet killer of enterprise web stacks. OWASP has been ranking it for years, and the reason is exactly what played out here. The attacker doesn't need to land code on the box. They convince a trusted server to make requests on their behalf, into systems that trust it back. In a PeopleSoft deployment, that trusted server typically sits next to the WebLogic application tier, the process scheduler, internal databases, and whatever identity provider stitches the SSO together.

The bash script left behind in the staging environment tells the story. The attackers mapped PeopleSoft configurations, viewed the process scheduler, and pulled WebLogic XML configs. That is classic reconnaissance: figure out where the data lives, where the service accounts authenticate, what's reachable from the compromised host. None of that requires a kernel exploit. It requires the server to be willing to fetch arbitrary URLs, which is the SSRF by definition.

Exfiltration was tidy. Data was compressed with zstd, which is fast and produces small artifacts, then shipped over an outbound SSH connection to 176.120.22.24, the same IP hosting the ShinyHunters data leak site. No fancy DNS tunneling, no domain fronting. Just SSH egress to a known-bad IP. That tells you something uncomfortable about the victims: outbound SSH to arbitrary internet hosts was apparently allowed from the PeopleSoft tier. In production environments I've seen, that egress path is the single most common gap on legacy app servers, because nobody wants to be the engineer who broke a 15-year-old batch job by tightening the firewall.

My take: the 9.8 severity is almost a distraction. The real lesson is the operational pattern. Two weeks of exploitation before vendor acknowledgment, half a patch, and an egress posture that lets 48GB walk out over SSH. The CVE is the spark. The fuel was already stacked.

Who Gets Burned

Higher education took the worst of it, and that's not random. Universities run sprawling PeopleSoft estates for student records, HR, and financials, often with thin security teams and procurement cycles measured in semesters. They also hold exactly the kind of data extortion crews love: names, dates of birth, financial aid records, immigration paperwork. The 68 percent concentration is a tell. ShinyHunters knew where the soft targets were and went there first.

But the blast radius doesn't stop at .edu domains. PeopleSoft is widespread in regulated enterprises, including financial services, healthcare systems, and large public sector employers. Any of them sitting on the same vulnerable build is one Shodan query away from being next. Teams I've worked with at fintechs typically run PeopleSoft for internal HR while the customer-facing stack gets all the security attention. Guess which one holds the executives' home addresses and bank details.

For boards and CTOs, the next 90 days look like this. Legal will want a written confirmation of exposure status. Insurers will ask for evidence of mitigation deployment dates. Regulators in jurisdictions with breach notification rules (GDPR, state-level US laws, sector-specific banking rules) will be measuring response timelines from May 27, not from your detection date. If you can't prove you weren't exploited during that window, you may have to assume you were.

The uncomfortable read: a 100-customer breach that targeted 300 endpoints suggests the attackers had a working scanner and a list. Anyone running a public-facing PeopleSoft instance should assume they were probed. The question is whether the SSRF actually fired before the stopgap went in.

Playbook for Security Teams

Treat this as active exploitation and act this week. Mandiant and Rapid7 are publishing indicators of compromise. Pull them, push them into your SIEM, and run retrospective hunts back to May 27. Don't wait for the full Oracle patch before applying the stopgap mitigation. Half a fix beats none when the actor is already in the building.

Concrete actions:

• Apply Oracle's stopgap mitigation for CVE-2026-35273 immediately on every PeopleSoft instance, internal or external. Check CISA KEV for status updates.
• Block outbound SSH and arbitrary egress from PeopleSoft application tiers. Allowlist only the destinations your batch jobs genuinely need. Yes, something will break. Fix it forward.
• Hunt for outbound connections to 176.120.22.24 and for zstd-compressed archives staged in temp directories on PeopleSoft hosts.
• Audit your WebLogic and process scheduler XML configs for credentials and service account tokens. Rotate anything that was readable from the app tier.
• Pull access logs for the PeopleSoft web tier back to May 27 and look for anomalous outbound fetch patterns consistent with SSRF probing.

For the CTO conversation: this is the moment to revisit whether legacy enterprise apps belong on the same network segment as your modern stack. PeopleSoft is not going away in most shops. Network isolation, strict egress, and a serious deprecation roadmap for the riskiest modules are the only durable answers. A single bad SSRF should not be able to reach your data leak in a 48GB zstd archive.

Key Takeaways

• CVE-2026-35273 is a 9.8 SSRF in Oracle PeopleSoft, exploited in the wild since May 27 and still only partially patched.
• ShinyHunters has hit roughly 300 endpoints across 100 organizations, with 68 percent in higher education and at least one confirmed extortion payment demand.
• The attack chain was unglamorous: SSRF, recon of PeopleSoft and WebLogic configs, zstd compression, SSH exfil to 176.120.22.24.
• Outbound egress controls on legacy app tiers are the cheapest mitigation you are not applying. Fix that this week.
• Assume probing if you ran public PeopleSoft between May 27 and the stopgap date. Hunt back, don't just patch forward.