dhy@ironhide: ~/site
dhy@ironhide:~/site$cat header.html
_____ _ _ _ _ | __ \| | | | | | | | | | | |_| | | | | | | | | _ | |_| | | |__| | | | | _ | |_____/|_| |_|_| |_| ~/dhy.tr — personal notes & technical writing

A 9.8 CVSS Zero-Day in Oracle PeopleSoft: How ShinyHunters Breached 100+ Universities

On June 11, 2026, Google's Mandiant team disclosed one of the most striking ERP zero-day attacks in recent memory. The vulnerability, CVE-2026-35273, lives in Oracle PeopleSoft Enterprise PeopleTools' "Environment Management Hub" component. The CVSS score is 9.8 out of 10 — essentially the maximum severity. The attack is a complete remote code execution (RCE) primitive: reachable over HTTP, unauthenticated, and requiring zero user interaction.

The ShinyHunters extortion crew actively exploited this flaw between May 27 and June 9, 2026. Oracle did not publish its advisory until June 10. That means the attackers had a two-week zero-day window during which defenders were flying blind. Mandiant's investigation matched vulnerable endpoints at over 100 organizations; 68% of them were in higher education, mostly universities in the United States.

In this post we'll walk through the attack's technical anatomy, the Linux server-side defense playbook, and what the incident teaches us about modern ERP security.

The Attack Anatomy: What Actually Happened

1. Discovery and Initial Access

The attackers hunted for internet-exposed Oracle PeopleSoft servers with the Environment Management Hub (PSEMHUB) endpoint reachable. That component normally handles "Updates Environment Management" operations. The vulnerability is reachable before any login check, which means: any time the path is allowed, the system is fully compromised.

This is why the score is 9.8: network access is sufficient, no password, no click, no interaction. The only thing required is for the endpoint to be reachable.

2. Command and Control Infrastructure

Mandiant explained how the attackers were spotted so quickly: they left their staging directories open. Five sequential IP addresses were running Python's SimpleHTTPServer on port 8888 — a developer convenience that becomes a disaster when exposed to the internet.

Inside those directories, the full attack toolkit was visible to anyone who looked:

  • A shared .bash_history file containing the attackers' full command history
  • MeshCentral remote-management agents disguised as Microsoft Azure binaries, calling home to azurenetfiles.net (a domain chosen to imitate Azure NetApp Files)
  • A lateral-movement script named [victim]_fanout.sh that SSH-sprays a hardcoded username/password list against internal hosts parsed from /etc/hosts

3. Data Exfiltration and Ransom Note

Data stolen from compromised PeopleSoft servers was compressed with zstd and shipped out over SSH to the server hosting ShinyHunters' public leak site. A marker file named README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT was dropped into PeopleSoft directories to make the message unambiguous to victims: "your data is with us."

4. Concrete Victims

The first confirmed victim was the University of Nottingham. Per Have I Been Pwned, the leaked dataset contains 455,000 unique email addresses — and not just addresses. The set includes names, postal addresses, phone numbers, passport numbers, ethnicity, and disability data. That's a phishing-ready dataset with everything identity fraud needs.

ShinyHunters has historically been a vishing-and-token-theft crew hitting SaaS platforms like Salesforce and Canvas. Moving to server-side zero-days against on-premises ERP is a step up in operational ambition. The open question is whether this was a one-off borrowed zero-day or the start of a long-term pivot into ERP exploitation.

Linux Server-Side: What Defenders Should Do

This attack is a textbook case of an enterprise Java application running on Linux — PeopleSoft, like most Oracle products, typically runs on Oracle Linux, RHEL, or SUSE. Even though the attack happens entirely at the HTTP layer, several practical defense layers are available on the Linux side.

1. Network Segmentation and Perimeter Control

The first and most urgent step: isolate PSEMHUB and PSIGW/HttpListeningConnector from the public internet. Oracle's own guidance:

  • On multi-server setups, disable the Environment Management Hub service
  • On single-server setups, remove the PSEMHUB application entirely
  • If neither is possible, block external access to /PSEMHUB/* (especially /PSEMHUB/hub) and /PSIGW/HttpListeningConnector at the perimeter

To enforce this on the Linux side with nftables, a quick lockdown rule set:

# /etc/nftables.d/peoplesoft-lockdown.nft
table inet peoplesoft_lockdown {
    chain input {
        type filter hook input priority 0; policy accept;

        # Restrict PSEMHUB reachability to internal management network
        tcp dport 443 ip saddr != 10.0.0.0/8 drop
    }
}

A more operationally friendly approach is path-based blocking at the nginx or apache reverse proxy layer:

# /etc/nginx/conf.d/peoplesoft-block.conf
location ~* ^/(PSEMHUB|PSIGW)/ {
    allow 10.0.0.0/8;        # Internal network
    allow 172.16.0.0/12;     # VPN range
    deny all;                  # Block everyone else
    return 403;
}

2. Hunting for Existing Compromise

You may already be compromised. Mandiant's IOC list gives Linux defenders concrete artifacts to look for:

  • WebLogic access logs showing external POST requests to /PSEMHUB/hub or /PSIGW/HttpListeningConnector
  • Unexpected .jsp files under the PSEMHUB.war web application directory
  • Surprising folders named logs, persistantstorage, or scratchpad under PSEMHUB paths
  • Recently changed .xml files under envmetadata/data/environment (XMLDecoder persistence that fires on the next restart)
  • Outbound SMB traffic on port 445 from PeopleSoft hosts to external destinations (used in the exploit chain to capture machine-account NetNTLM hashes)

Quick triage on a Linux host:

# Suspicious JSP files
find /opt/oracle/peoplesoft -name "*.jsp" -newer /etc/issue 2>/dev/null

# XML files changed in the last 14 days
find /opt/oracle/peoplesoft -path "*envmetadata*" -name "*.xml" -mtime -14

# Outbound SMB connections
ss -tnp | grep ':445 '

# C2 domain references in application files or logs
grep -r "azurenetfiles" /opt/oracle/peoplesoft/ 2>/dev/null
journalctl -u peoplesoft --since "14 days ago" | grep -i "azurenetfiles"

3. WAF Alone Is Not Enough

Mandiant specifically warns that WAF body-inspection rules can be bypassed for zero-days like this one. Defense-in-depth is the only sane approach: WAF at the perimeter plus network segmentation plus application-layer authentication plus file integrity monitoring (AIDE, Tripwire) working together.

To monitor the PSEMHUB directories with AIDE, add to /etc/aide/aide.conf:

/opt/oracle/peoplesoft/PSEMHUB Full
/opt/oracle/peoplesoft/envmetadata Full
!/opt/oracle/peoplesoft/PSEMHUB/logs$

Any change to those critical paths is then logged for review.

The Bigger Picture: ERP Is Now a Primary Target

This attack is the latest data point in a clear trend: enterprise software is firmly in the crosshairs of zero-day operators. TrendAI's Zero Day Initiative reports an average of 60–70 new ERP vulnerabilities per year, the majority in Oracle E-Business Suite, SAP NetWeaver, and PeopleSoft. ERPs are attractive targets for three reasons:

  • Data density: A single ERP host typically holds personnel records, financial data, student records, health information — all the regulated data types, in one place
  • Criticality: Taking ERP offline directly impacts business continuity, which increases ransom pressure
  • Legacy stickiness: Even though PeopleTools 8.61 and 8.62 are officially "supported," installations five or more years old remain common

The disproportionate impact on universities is no accident. University IT teams typically operate under tight budget and headcount constraints, patch cycles slip by months, and aging ERP frontends exposed to the internet often go untracked. This pattern is identical at small and mid-sized businesses and public agencies, including universities in Turkey and across the region.

Closing: Beyond "Patch and Pray"

CVE-2026-35273 sits in the worst possible category for an enterprise vulnerability: network-reachable, unauthenticated, RCE without user interaction. ShinyHunters was actively using it for two weeks before Oracle's advisory. The classic "publish, then patch" workflow simply cannot keep up with this pace.

Three things need to happen, in order:

  1. Know your patch cadence: Track Oracle's Critical Patch Update (CPU) calendar. Stay on a supported PeopleTools version. Don't let support contracts lapse on systems holding regulated data.
  2. Shrink your exposed surface: Inventory every internet-facing ERP endpoint. Push what you can behind a VPN or an internal-only network. The smallest possible public footprint is the goal.
  3. Continuously monitor: AIDE or Tripwire plus centralized log collection (Graylog, Loki) plus outbound traffic anomaly detection. None of these are optional anymore.

The Linux ecosystem has the tools. The hard part is operational discipline: keeping the monitoring actually running, the alert routing actually working, and the response plan actually rehearsed. CVE-2026-35273 is a reminder that there is no guarantee your server won't be the next target.

In the next post, we'll look at how AI-assisted vulnerability research — the same approach that produced the FFmpeg 21-zero-day haul a few days ago — is changing both offense and defense. The discovery-to-exploit window is compressing from months to hours. Understanding that shift is no longer optional for defenders.

Sources:

dhy@ironhide:~/site$