Oracle PeopleSoft RCE Exploited by ShinyHunters (CVE-2026-35273)

TL;DR

CVE-2026-35273 is an unauthenticated remote takeover of Oracle PeopleSoft, exploited as a zero-day and exploited again months after its fix.

• Three flaws reported by the Zero Day Initiative work as one chain: a server-side request forgery in the Integration Gateway (PSIGW), a loopback address trusted by default in the Environment Management Hub (PSEMHUB), and two code-execution paths inside PSEMHUB. Oracle patched all three under the single CVE in its June 10, 2026 security alert.
• PeopleSoft Enterprise PeopleTools 8.61 and 8.62 are the supported affected releases. CVSS v3.1 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), rated by Oracle.
• ShinyHunters (tracked as UNC6240 by Mandiant and Google Threat Intelligence Group) exploited the chain as a zero-day from May 27 to June 9, 2026, mostly against universities, and again in a wider September wave across higher education, technology, IT services, healthcare, agriculture, transport and government. CISA added the CVE to its Known Exploited Vulnerabilities catalog on June 12.
• Apply Oracle's June 10 security alert patch and stay on a supported PeopleTools release. Until you patch, disable or remove the Environment Management Hub; patching closes the door but does not evict an attacker already inside.

Am I affected?

You are affected if both of these hold:

• Your deployment runs PeopleSoft Enterprise PeopleTools 8.61 or 8.62, the two supported releases the CVE record lists as affected. If you run an older, unsupported PeopleTools release, Oracle's alert says such releases are not tested for this vulnerability and are likely also affected. Treat the chain as present and plan a move to a supported release.
• The Integration Gateway and the Environment Management Hub are deployed, which is the default Environment Management Framework setup. Both run as separate Oracle WebLogic applications, and the chain needs both: PSIGW to reach PSEMHUB, and PSEMHUB to execute code.

Confirm the PeopleTools release with your PeopleSoft administrator or in My Oracle Support, then check the two paths the chain needs. Neither requires a login. Test the Integration Gateway from outside your network, because it is the entry point. Test the Environment Management Hub from the PeopleSoft server itself: the chain reaches it through the gateway from the loopback address, so it only has to be deployed, not exposed:

# From a network outside your perimeter: the entry point should be unreachable
curl -s -o /dev/null -w "%{http_code}\n" https://<your-peoplesoft-host>/PSIGW/HttpListeningConnector
# On the PeopleSoft web server itself: any response means the Hub is deployed
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:<pia-port>/PSEMHUB/hub

On the first check, any response other than a timeout or a connection refusal means the entry point is exposed and needs the exposure decisions below. On the second, any response means the Hub is deployed: a perimeter rule on /PSEMHUB/ alone does not stop the chain, because the forged request comes from the server itself, so disable or remove the Hub as described below.

Oracle's security alert is the primary source for the patch and the exact version matrix: https://www.oracle.com/security-alerts/alert-cve-2026-35273.html

Mandiant's June 2026 report says it notified more than 100 global organizations whose IP addresses correlated with potentially vulnerable endpoints; 68 percent of them were higher-education institutions.

How do I fix it?

Apply the patch from Oracle's security alert of June 10, 2026, through your normal PeopleSoft patch process, and stay on a supported PeopleTools release. Mandiant's September report is explicit that web application firewall rules and path-based blocking are not a substitute for patching.

If you cannot patch yet, Mandiant, citing Oracle's security alert guidance, lists the steps that remove the exposure the chain needs:

• In multi-server setups, disable the Environment Management Hub (EMHub) service if you do not use it for patching. In single-server setups, remove the PSEMHUB application entirely. Mandiant notes that restricting these admin endpoints does not break normal user sessions.
• If you cannot disable the EMHub service, block external access to /PSIGW/HttpListeningConnector and /PSEMHUB/* at the network perimeter or firewall level. The /PSIGW/HttpListeningConnector rule is the one that stops this chain: the forged request reaches the Hub from the server itself, so it never crosses the perimeter. The /PSEMHUB/* rule still matters, because in the September wave attackers also sent requests straight to an exposed Hub.
• Enforce any rule on the decoded, normalized path. In the September wave, ShinyHunters slipped past WAF rules that blocked /PSEMHUB/ by requesting /%50SEMHUB/ instead: many rules match the path's plain text, while the PeopleSoft server decodes it and serves the page. Mandiant warns that attackers may use any percent-encoded, mixed-case or otherwise non-normalized variant.

If you may already be compromised, treat any host with a web shell as compromised, preserve evidence, and rotate every credential reachable from the PeopleSoft tier. ShinyHunters steals data and then demands payment, so prepare for extortion. Patching closes the door; the sources below do not claim it evicts anyone already inside.

What is the root cause?

Oracle walled the Environment Management Hub off with a host allowlist that trusts the loopback address by default, and left the Integration Gateway able to forward any request to any URL; together the wall becomes a door.

ZDI's Bobby Gould, with Minh Giang and Lucas Miller of TrendAI Research, reported the chain to Oracle on June 10, 2026, and published the breakdown on October 27, 2026. Three flaws across the two components:

Flaw 1: SSRF in PSIGW (ZDI-CAN-31816). The Integration Gateway exchanges messages between the PeopleSoft server and remote systems through Listening and Target Connectors. A POST to /PSIGW/HttpListeningConnector that names the HttpTargetConnector handler lets the attacker choose both the URL the gateway contacts and the complete payload it forwards there, in the request's Data field. ZDI decompiled the handler and found no validation that the traffic is legitimate or bound for a valid target: it takes the target URL from the attacker's request, builds the request object, applies the HTTP method and sends the attacker's content as-is.

The enabler: PSEMHUB trusts loopback by default. The Environment Management Hub is an internal admin interface that is supposed to answer only to trusted hosts. Its validateClient method checks the requesting client against /envmetadata/config/allowedhosts.properties, and the default file that ships with PeopleSoft already lists localhost; the allowed set also holds the server's own resolved hostname and IP. So a request that arrives through the SSRF from 127.0.0.1 looks like it came from the machine itself, and the trust check passes.

Flaw 2: external control of file path in PSEMHUB (ZDI-CAN-31818). PSEMHUB's ExecuteProcessActivityCommand handler exists to let remote clients write log entries to the server's filesystem. The caller controls both the file contents, in the m_line parameter, and the absolute path on disk, in m_targetFile. The handler performs no validation that the path points to a legitimate log directory. Writing a JSP web shell into the PSEMHUB WAR path gives immediate code execution as the PeopleSoft service account.

Flaw 3: deserialization of untrusted data in PSEMHUB (ZDI-CAN-31817). Using any file-write primitive, an attacker places a malicious XML file inside [docroot]/envmetadata/data/environment/. The next time the PSEMHUB HubServlet class initializes, after a system or service restart, it loads every file from that directory and passes each to Java's XMLDecoder. XMLDecoder instantiates and configures the objects described in the XML during parsing, so the attacker's payload executes before the cast to Environment throws an exception. This path needs no web shell and is less likely to be caught by standard detection.

How is it exploited?

The whole chain is unauthenticated: nothing in it asks for a PeopleSoft login. Step by step, following ZDI's analysis:

1. The attacker POSTs to /PSIGW/HttpListeningConnector, names the HttpTargetConnector handler, sets the target to the loopback address (for example http://127.0.0.1:8000) and puts the inner request in the Data field.
2. The Integration Gateway forwards that inner request to the loopback target. It arrives at PSEMHUB appearing to originate from the machine itself.
3. validateClient checks the requester against allowedhosts.properties, finds the loopback address in the default list, and returns true.
4. The attacker reaches PSEMHUB's command handlers through the SSRF and calls ExecuteProcessActivityCommand, supplying web shell contents in m_line and an absolute path inside the PSEMHUB WAR in m_targetFile.
5. The web shell is written to the application directory, and requests to it execute commands as the PeopleSoft service account. Alternatively, the same write primitive plants an XML file in envmetadata/data/environment/, and the payload runs through XMLDecoder at the next service restart, with no web shell to find.

In the observed campaigns, the attackers went further: Mandiant's triage of the June staging servers found MeshCentral agents disguised as Microsoft Azure services and a lateral-movement and defacement script, and stolen data from victims appeared on the ShinyHunters data leak site. In the September wave, Mandiant saw JSP web shells such as x.jsp and u.jsp written into the PSEMHUB WAR, a trojanized installer carrying the SIDEEYE backdoor, and fileless command execution that writes nothing to disk.

How does the attack flow?

One request chain, from an unauthenticated internet position to code execution as the PeopleSoft service account:

What can an attacker do?

Successful exploitation gives unauthenticated remote code execution with the PeopleSoft service account's privileges on the PeopleSoft web tier. Mandiant notes that this account can read PeopleSoft configuration files, database connection strings and application data, and UNC6240 used the foothold for credential spraying, lateral movement, data theft and extortion. Conditions it needs:

• Network access to the PSIGW listening connector and, through it, to PSEMHUB. No PeopleSoft credentials, no user interaction.
• The Environment Management Framework deployed with its defaults: PSEMHUB present, allowedhosts.properties still carrying the loopback entry, and the PSIGW HttpListeningConnector reachable.
• For the deserialization path only, a service or system restart after the XML file is planted.

Why does the fix work?

Oracle's June 10, 2026 security alert patched all three flaws under the single CVE; ZDI reports it is coordinating with Oracle to assign a separate CVE to each. Neither Oracle's alert nor ZDI's write-up publishes a source diff or explains how each of the three flaws is closed.

The workaround follows from the chain's structure: both code-execution paths ZDI describes live inside PSEMHUB, so removing PSEMHUB breaks the published chain even while the PSIGW SSRF remains, although the SSRF can still reach any other service on the loopback address. The September wave shows the limit of blocking alone: attackers adapted to path-based rules with /%50SEMHUB/, which is why Mandiant says path-based blocking is no substitute for the alert's patch.

How do I check if I was compromised?

Mandiant's June and September 2026 reports give specific hunts; run them against the period since May 27, 2026.

In the PIA WebLogic access logs, search for POST requests to /PSEMHUB/hub and /PSIGW/HttpListeningConnector originating from external source IPs. Legitimate Integration Broker partners also post to the listening connector, so check each source against your known partners; a hit from an unknown external address before your patch date points to the chain.

In the September wave the same attack appears as /%50SEMHUB/, and the web shells are requested as .jsp files under it, so decode the path and match it regardless of case:

# PIA WebLogic access log; decode the path first so /%50SEMHUB/ and other encoded forms match too
python3 -c 'import sys, urllib.parse; sys.stdout.writelines(urllib.parse.unquote(l) for l in open(sys.argv[1], errors="replace"))' <PS_CFG_HOME>/webserv/<domain>/servers/PIA/logs/PIA_access.log | grep -iE "POST /(PSEMHUB|PSIGW/HttpListeningConnector)|/PSEMHUB/[^ ]*\.jspx?"

On the web-tier filesystem of every WebLogic node, not only the first one you find, look for the files the chain and the web shells leave:

# JSP, JSPX and EXE files in the PSEMHUB and PORTAL WARs; flag any that are not part of the shipped product
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PORTAL.war \( -name "*.jsp" -o -name "*.jspx" -o -name "*.exe" \)
# XML files the deserialization path loads at the next restart; review any recently created or modified
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/envmetadata/data/environment -name "*.xml" -ls
# Unauthorized content in the hub's transactions directory
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/envmetadata/transactions
# Unexpected logs, persistantstorage or scratchpad directories under PSEMHUB
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war -type d \( -name logs -o -name persistantstorage -o -name scratchpad \)

Then the indicators Mandiant published, mostly recovered from the attacker staging servers in June:

• MeshCentral agent binaries named meshagent32-azure-ops.exe, meshagent64-azure-ops.exe and meshagent64-v2.exe, hardcoded to the command-and-control address wss://azurenetfiles.net:443/agent.ashx, a domain mimicking Microsoft Azure NetApp Files.
• The staging IP addresses 142.11.200.186 through 142.11.200.190, hosting Python SimpleHTTP servers on port 8888, and 176.120.22.24, the public mirror of the ShinyHunters data leak site that the staging servers connected to over SSH.
• A lateral-movement and defacement script named after the victim, [victim_abbreviation]_fanout.sh.
• Outbound SMB traffic (TCP port 445) from PeopleSoft servers to untrusted external destinations in firewall logs and NetFlow data.
• From the September report: the SIDEEYE command-and-control address 162.219.30.165 on TCP ports 3333 and 3334, and MeshAgent infrastructure on azurenetfiles.net, microsoft-entra.net, enroll.azuredevice.cloud and winmanage-me.network (104.219.234.138).

Timeline

• 2026-05-27 to 2026-06-09: ShinyHunters (UNC6240) exploits the chain as a zero-day, before any fix or advisory exists, mostly against universities. The attacker staging environment was set up on May 27 at 22:14 UTC (Mandiant/GTIG).
• 2026-06-09: stolen data from compromised organizations appears on the ShinyHunters data leak site; public reports expose open directories on the staging servers.
• 2026-06-10: ZDI reports the three flaws to Oracle; Oracle releases its out-of-band security alert fixing all three under CVE-2026-35273.
• 2026-06-11: the CVE record is published with the CVSS v3.1 9.8 vector; Mandiant and GTIG publish their attribution and report having notified more than 100 organizations, 68 percent in higher education.
• 2026-06-12: CISA adds CVE-2026-35273 to its Known Exploited Vulnerabilities catalog, federal due date June 15, 2026.
• 2026-09-25: Mandiant reports a renewed mass-exploitation wave that uses the /%50SEMHUB/ WAF bypass and spans higher education, technology, IT services, healthcare, agriculture, transport and government, with web shells on dozens of systems worldwide.
• 2026-10-27: ZDI publishes the three-flaw breakdown of the single CVE; separate CVEs for each flaw are being coordinated with Oracle.
• 2026-10-29: this post.

FAQ

Is blocking the PSEMHUB path at my firewall enough?

No. Mandiant is explicit that path-based blocking is not a substitute for patching, and the September wave proved the point: attackers requested /%50SEMHUB/ and bypassed rules that matched the plain path, because PeopleSoft decodes the path and serves the page. Blocking helps until you patch, and the rule must match the decoded form.

Does applying the patch remove an attacker who is already inside?

No source claims that it does. Oracle's alert does not address eviction, and Mandiant's guidance to rotate every credential reachable from the PeopleSoft tier and hunt for web shells assumes the attacker stays. Patch, then treat the host as an incident.

Was only the education sector attacked?

The June wave was concentrated there: 68 percent of the more than 100 organizations Mandiant notified were academic institutions. The September Mandiant report describes a wider wave across higher education, technology, IT services, healthcare, agriculture, transport and government, with web shells on dozens of systems worldwide.

Is this one vulnerability or three?

Three. ZDI reported the PSIGW SSRF (ZDI-CAN-31816), the PSEMHUB file-path control (ZDI-CAN-31818) and the PSEMHUB deserialization (ZDI-CAN-31817) as distinct vulnerabilities, and Oracle patched all three under the single June CVE. ZDI is coordinating with Oracle to assign a separate CVE to each.

I run an older PeopleTools release. Am I affected?

The CVE record and Oracle's alert list 8.61 and 8.62, the supported releases, as the affected versions. The alert says releases outside Premier or Extended Support are not tested and are likely also affected, so treat the chain as present and move to a supported, patched release.

Find exposed PeopleSoft endpoints with Ostorlab

Use Ostorlab Attack Surface Discovery to inventory the internet-facing hosts you own and find exposed PeopleSoft Integration Gateway and Environment Management Hub endpoints, the /PSIGW/HttpListeningConnector and /PSEMHUB/ paths this chain needs, so you can verify that neither is reachable from outside your perimeter.

References

• ZDI, Bobby Gould, "CVE-2026-35273: SSRF to RCE in Oracle PeopleSoft", October 27, 2026: the three-flaw breakdown, the validateClient analysis, the PSIGW request and handler behavior, and both code-execution paths: https://www.zerodayinitiative.com/blog/2026/10/20/cve-2026-35273-ssrf-to-rce-in-oracle-peoplesoft (checked October 29, 2026)
• Oracle security alert CVE-2026-35273, June 10, 2026: the fix, the affected versions 8.61 and 8.62, the CVSS 9.8 risk matrix, the reporter credits and the note on unsupported releases: https://www.oracle.com/security-alerts/alert-cve-2026-35273.html (checked October 29, 2026)
• CVE-2026-35273 record: PeopleTools 8.61 and 8.62 affected, CVSS v3.1 9.8, Oracle CNA: https://cveawg.mitre.org/api/cve/CVE-2026-35273 (checked October 29, 2026)
• CISA KEV catalog: CVE-2026-35273 added June 12, 2026, federal due date June 15, 2026, required action under BOD 26-04: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-35273 (checked October 29, 2026)
• Mandiant and Google Threat Intelligence Group, "ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit", June 11, 2026: the May 27 to June 9 zero-day attribution, the 100+ notified organizations with 68 percent in higher education, the staging-server indicators, the MeshCentral agents and the remediation and hunting guidance: https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-targets-education-sector-oracle-exploit (checked October 29, 2026)
• Mandiant and Google Threat Intelligence Group, "ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft", September 25, 2026: the wider-sector wave, the /%50SEMHUB/ WAF bypass, the web shell and SIDEEYE indicators, and the updated hunting and credential-rotation guidance: https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft (checked October 29, 2026)