Cyber Threats PeopleSoft PeopleTools Pre-Authentication RCE: A PSIGW SSRF Chain That Executes Inside the JVM 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) Save to Folio Key takeaways A pre-authentication remote code execution (RCE) chain in Oracle PeopleSoft PeopleTools reaches an internal-only management servlet through a server-side request forgery (SSRF) in the PSIGW gateway, then gains code execution through Java XMLDecoder deserialization. Oracle assigned CVE-2026-35273 (CVSS 9.8) and released an out-of-band patch on June 10, 2026. The chain affects PeopleTools 8.61, and 8.62, including installations that were fully patched before the out-of-band advisory, because Oracle’s prior serialization-filter hardening does not cover this XMLDecoder code path. The chain is behaviorally quiet : Its final step executes inside the WebLogic JVM on a web-tier restart, with no spawned child process and no required outbound beacon. Detection logic that watches for “Java spawns a shell” or for an on-the-wire exploit signature will, in the common case, see nothing. TrendAI™ protections address this threat across the network and endpoint layers, including TrendAI™ Deep Discovery rules and TrendAI™ TippingPoint, TrendAI Vision One™ Server and Workload Protection (SWP), and TrendAI™ Deep Security filters. More guidance may be found in this entry’s recommendations section. 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 about 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. What PSIGW and PSEMHUB actually are Oracle PeopleSoft runs human-resources, financials, and campus-management workloads for large enterprises, government agencies, and universities. Two PeopleSoft components matter here: The Integration Broker is PeopleSoft’s messaging layer, the machinery that lets PeopleSoft exchange data with other systems. It exposes a public-facing gateway, the PeopleSoft Integration Gateway (PSIGW) , and that gateway publishes an unauthenticated listening connector at /PSIGW/HttpListeningConnector. Its job is to accept inbound integration messages. The PeopleSoft Environment Management Hub (PSEMHUB) is a separate, internal-only servlet used to manage PeopleSoft environments. It is not meant to be reachable from untrusted networks. Access to it is gated by an IP-based allow-list check named validateClient, which is supposed to ensure only trusted hosts can talk to the hub. 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. Methodology 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 next 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 previous patches remained vulnerable until Oracle's patch. Step 6 - Post-exploitation options From code execution, the operator chooses what comes next. Two options were seen in analysis: Web shell. Drop a JSP web shell into the PSEMHUB.war docroot for interactive, persistent access. Credential coercion. Coerce outbound SMB/445 to capture or relay the machine account’s NetNTLM credentials. The one mechanic that makes this chain hard to see 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”: Integration Broker east-west traffic flagged by an unrelated signature. PeopleSoft’s own internal Integration Broker SOAP/XML can trip network signatures written for other products; a Django-exploit signature, for example, will misfire on legitimate PSIGW traffic. Before escalating any PSIGW hit, confirm the source is genuinely external — internal-to-internal Integration Broker chatter is normal east-west traffic, not exploitation. Legitimate writes under envmetadata/. PeopleSoft Change Assistant and Veritas NetBackup both write to these paths in normal operation. Any persistence rule that does not allow-list these will drown in false positives. MITRE ATT&CK techniques Tactic Technique ID How it appears here Initial access Exploit public-facing application T1190 Unauthenticated SSRF at POST /PSIGW/HttpListeningConnector, pivoting to the internal PSEMHUB hub and triggering XMLDecoder code execution Persistence Server software component: web shell T1505.003 Optional JSP web shell dropped into the PSEMHUB.war docroot Credential access Forced authentication T1187 Optional outbound SMB/445 coercion for NetNTLM capture or relay 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. Recommendations Oracle released a