Skip to content
PeopleSoft PeopleTools Pre-Authentication RCE: A PSIGW SSRF Chain That Executes ...

PeopleSoft PeopleTools Pre-Authentication RCE: A PSIGW SSRF Chain That Executes ...

Trendmicro June 18, 2026

A pre-authentication remote code execution (RCE) chain in Oracle PeopleSoft PeopleTools abuses the Integration Broker's PSIGW gateway to execute code inside the application server's Java virtual machine (JVM), evading behavioral and network sensors.

By: Jacob Santos Jun 18, 2026 Read time: ( words)

Enterprise resource planning systems handle some of the most sensitive data an organization holds, but they are also deeply connected to internal infrastructure. When a pre-authentication remote code execution (RCE) chain surfaces in one of the most widely deployed ERP platforms and is already being exploited in the wild, it warrants close attention. In this blog entry, TrendAI™ Research details a technical analysis of an active pre-authentication exploitation chain in Oracle PeopleSoft PeopleTools, the development platform used to build and maintain PeopleSoft applications. PeopleSoft PeopleTools versions 8.61, and 8.62 are affected, per Oracle’s advisory.

On June 10, 2026, Oracle issued an out-of-band security alert for CVE-2026-35273 , a critical unauthenticated remote code execution vulnerability (CVSS 9.8) in the Updates Environment Management component of PeopleSoft Enterprise PeopleTools. The vulnerability was reported to Oracle through the TrendAI™ Zero Day Initiative™ (ZDI) . One day later, Mandiant published a report attributing in-the-wild exploitation to SHADOW-AETHER-015 (ShinyHunters), documenting a campaign that ran from May 27 through June 9, 2026, two weeks before the vendor advisory and targeted over 100 organizations, predominantly in higher education.

Pre-authentication RCE on an enterprise application is severe, but not new. The notable property of this vulnerability is not its impact, but its near-total lack of observability. The final code-execution step runs through Java’s XMLDecoder inside the application server’s own Java virtual machine (JVM), fires on a restart rather than on the inbound request, and needs no child process and no outbound beacon to succeed. A defender watching the usual places sees a quiet system.

Our researchers discovered new information this vulnerability, which was responsibly disclosed to Oracle as part of our investigation. This blog documents the chain step by step, explains the single mechanic that makes it so hard to see, and turns that into concrete guidance for defenders. TrendAI™ also published Security Alert KA-0023679 with an overview and initial detection guidance.

Oracle PeopleSoft runs human-resources, financials, and campus-management workloads for large enterprises, government agencies, and universities. Two PeopleSoft components matter here:

The vulnerability lives between those two components: A public gateway that will faithfully relay a request, and an internal servlet that trusts requests which appear to come from the local host. Bridge that seam and an external, unauthenticated attacker is suddenly talking to an internal management endpoint.

The chain proceeds in six steps. The description below is reconstructed from Trend ZDI reproduction of the exploit and from incident analysis.

Step 1 - Pre-authentication SSRF at the gateway

The attacker sends an unauthenticated POST to the Integration Broker’s listening connector:

POST /PSIGW/HttpListeningConnector

The request body is a PeopleSoft IBRequest XML message whose ConnectorParam carries a URL that points back at the server itself; for example, http(s)://localhost/PSEMHUB/hub.

Step 2 - The validateClient bypass

Because the gateway issues that follow-on request from itself , the inbound call to /PSEMHUB/hub appears to originate from localhost. That satisfies the IP-based validateClient allow-list meant to restrict the hub to trusted hosts. This is a textbook server-side request forgery (SSRF) : The attacker borrows the server’s own identity to reach an endpoint they could never reach directly, and they now talk to the PSEMHUB hub servlet pre-authentication.

Step 3 - Staging on disk

Through the hub, the attacker writes attacker-controlled content under the transaction staging directory envmetadata/transactions/.

Step 4 - Persistence as a planted XML object

A crafted XML payload is written under envmetadata/data/environment/. At this point nothing has executed; the payload sits dormant on disk, waiting.

Step 5 - Deserialization to code execution

On the web-tier restart , PSEMHUB’s XMLDecoder deserializes the planted XML and instantiates attacker-chosen objects. That yields RCE as the web-tier service account : SYSTEM on Windows, psadm2 on Unix-like hosts. This is the step that earlier patching did not address: Oracle’s prior serialization-filter hardening does not cover the XMLDecoder path, which is why installations that had applied all patches remained vulnerable until Oracle's patch.

Step 6 - Post-exploitation options

From code execution, the operator chooses what comes . Two options were seen in analysis:

The single most important detail for defenders is in Step 5: The trigger is a restart, and the execution is in-process.

There is a deliberate time gap between persistence (Steps 3–4) and execution (Step 5). When execution finally happens, it happens inside the WebLogic JVM . XMLDecoder deserialization and JSP web shell execution produce no child-process telemetry unless a web shell explicitly runs an operating-system command. A successful exploitation that stops at in-JVM code execution therefore generates none of the parent/child process anomalies that behavioral detection relies on, and the SSRF pivot itself targets localhost — a loopback request that never crosses a network sensor.

This is, by construction, a chain built to leave little behind. In-JVM deserialization and web shell instantiation produce no file or process payload unless an operating-system command runs, and a loopback SSRF produces nothing on the wire. Conventional detection that waits for an on-the-wire exploit signature or a “Java spawns a shell” anomaly will, in the common case, have nothing to fire on — which is precisely why the hunt has to move to the persistence paths and the restart instead.

Two benign patterns can look superficially like the chain, and both must be excluded before anything is called “exploitation”:

Table 1. ATT&CK mapping for the PSEMHUB chain. The server-side deserialization that drives code execution is treated as the mechanism of T1190 rather than a separate technique, because ATT&CK has no clean mapping for server-side XMLDecoder deserialization.

Oracle released an out-of-band patch on June 10, 2026; apply it immediately on all PeopleTools 8.61 and 8.62 installations. Given that exploitation was observed as early as May 27, 2026, investigate for signs of compromise even after patching. Beyond patching, the following exposure-reduction and detection-engineering measures provide defense in depth:

Guidance also differs by role:

The vulnerability and its chain are well-sourced, and they describe a sobering pattern: A serious pre-authentication RCE can run end to end while producing almost no telemetry, because its final step lives inside the application’s own JVM and fires on a restart rather than on the inbound request. A quiet system is not a safe one; silence is the predictable shape of a chain built to execute in-process and fire on a restart.

That observability gap is the lasting lesson. The specific vulnerability is now patched, but the pattern of a public-facing gateway relaying requests to an internal servlet, with execution deferred to an in-JVM restart will appear again in other enterprise applications. Defenders who build detection around persistence paths and restart behavior, rather than waiting for process-tree anomalies or network signatures, will be better positioned when it does.

TrendAI Vision One™ customers can act on this threat through coverage across the network and endpoint layers. The following rules and filters address this chain:

TrendAI™ Deep Discovery™

TrendAI™ TippingPoint™

TrendAI™ Deep Security™, TrendAI Vision One™ Server and Workload Protection (SWP), and TrendAI Vision One™ Endpoint Security IPS

TrendAI Vision One™ Threat Intelligence Hub provides the latest insights on emerging threats and threat actors, exclusive strategic reports from TrendAI™ Research, and TrendAI Vision One™ Threat Intelligence Feed in the TrendAI Vision One™ platform.

Emerging threat: CVE-2026-35273: Pre-Authentication Remote Code Execution in PeopleSoft PeopleTools (PSEMHUB)

Threat actor: SHADOW-AETHER-015

TrendAI Vision One™ Intelligence Reports (IOC sweeping)

CVE-2026-35273: Pre-Authentication Remote Code Execution in PeopleSoft PeopleTools (PSEMHUB)

TrendAI Vision One™ customers can hunt for the chain’s footprint using TrendAI Vision One™ XDR Data Explorer App. Because the SSRF body (the IBRequest ConnectorParam URL) is inspected at the network sensor layer, deep request-body matching is best left to dedicated network signatures — the XDR Data Explorer App hunts the observable metadata around it: The request path, the on-disk artifacts, and the outbound SMB. The queries below are a starting set; field availability varies by data source and sensor, so validate field names against your tenant schema before running them.

Inbound SSRF entry and direct hub access (Network Activity Data):

request:"/PSIGW/HttpListeningConnector" AND (request:"PSEMHUB/hub" OR request:"localhost" OR request:"127.0.0.1") request:"/PSEMHUB/hub"

On-disk staging and XMLDecoder persistence (Endpoint Activity Data), with the two known-benign writers excluded:

(objectFilePath:"envmetadata/transactions" OR objectFilePath:"envmetadata/data/environment") AND NOT (processFilePath:"ChangeAssistant" OR processFilePath:"NetBackup" OR processFilePath:"bpbkar" OR processName:"psae")

Optional JSP web shell in the PSEMHUB web application (Endpoint Activity Data):

objectFilePath:"PSEMHUB.war" AND objectFilePath:".jsp"

Hunt patterns (detection use — not attacker-owned indicators)

Table 2. Hunt patterns for the PSEMHUB chain. These are detection and hunting aids, not attacker-controlled indicators, and several require allow-listing to control false positives.