CVE-2026-35273: SSRF to RCE in Oracle PeopleSoft

On September 25, 2026, Mandiant released a report regarding continued mass exploitation of CVE-2026-35273 by the ShinyHunters group. TrendAI’s Zero Day Initiative first reported this CVE to Oracle on June 10, 2026, following an investigation I conducted with Minh Giang and Lucas Miller of TrendAI Research. Although Oracle issued a patch under a single CVE, we reported three distinct vulnerabilities across multiple PeopleSoft components. We are coordinating with Oracle to assign separate CVEs for each issue. In this blog post, we will walk through each of these vulnerabilities, starting with a Server-Side Request Forgery (SSRF) vulnerability. We will also review the validateClient method that Oracle introduced to allow PeopleSoft system administrators to restrict access to certain functionality. Spoiler alert: the SSRF allows attackers to make requests that satisfy this validation and access endpoints vulnerable to remote code execution (RCE). Overview There are two main components involved here, both served as individual Oracle WebLogic applications. The first, the PeopleSoft Environment Management Hub (PSEMHUB), is part of Oracle’s Environment Management Framework. This component implements the validateClient method, ensuring only trusted clients can reach PSEMHUB functionality. Because this is an internal management interface, it makes sense that Oracle would restrict access to its web endpoints. However, this also means it’s a prime target for attackers looking to pivot from their existing, low-privileged access. The second, the PeopleSoft Integration Gateway (PSIGW), contains functionality for exchanging messages between the PeopleSoft server and remote systems. This is accomplished using a set of Listening and Target Connectors. One such connector is the HttpListeningConnector, which translates data from inbound HTTP requests into the format supported by the specified Target Connector before routing the request to the desired URL. In this chain, attackers specify the HttpTargetConnector. The diagram below shows how an attacker like ShinyHunters can combine these vulnerabilities to compromise PeopleSoft systems. Notice that the attacker cannot simply hit the PSEMHUB functionality directly: Bug 1: PSIGW Server-Side Request Forgery (ZDI-CAN-31816) Now let’s take a look at how the PSIGW SSRF provides attackers with a foothold in the PeopleSoft application. An example malicious request to PSIGW shows just how powerful this is for an attacker. We control the URL to hit AND the full payload to send! At [1], the attacker sends a POST request to /PSIGW/HttpListeningConnector At [2], the HttpTargetConnector handler class is specified At [3], the target is PeopleSoft on the loopback interface at http://127.0.0.1:8000, satisfying the validateClient logic At [4], the full POST request payload is specified in the Data field, to be forwarded to the target URL at [3] The HttpTargetConnector handler appears below. Note there is no validation to ensure this traffic is legitimate and bound for a valid target. I've done my best to pull out the important parts of this 800+-line function. If you want a fun side quest, go decompile this for yourself and check it out. I hope you like spaghetti! At [1], retrieve the target URL from the attacker's request At [2], create an httpObj using the URL from [1] At [3], retrieve the HTTP method (POST) and apply it to the httpObj from [2] At [4], send the content data seen in the Data tag of the network request. This content is sent as-is using the HTTP parameters configured in the httpObj To fully understand why this SSRF is valuable, here is the validateClient method I mentioned earlier: At [1] and [2], the validateClient method pulls the hostname and IP of the requesting client At [3], a file path is built to the /envmetadata/config/allowedhosts.properties file, which contains the list of hosts allowed to access functionality protected by validateClient At [4], the server checks if the allowedList set contains any entries. The first time this path is hit, the set is empty, so execution continues into the client list refresh block At [5], that allowedhosts.properties file is read and iterated over At [6] and [7], each allowed host is added to the allowedList set, including the default localhost entry alongside the server's resolved hostname and IP address At [8] and [9], if the requesting host is found in the allowedList set, validateClient returns true We can see the localhost entry in the default allowedhosts.properties that ships with PeopleSoft: While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB. Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access. Bug 2: PSEMHUB External Control of File Path (ZDI-CAN-31818) Now that the attacker can make requests to the PSEMHUB endpoints using the PSIGW SSRF, let's see how they can turn that into RCE. The first path to code execution uses an External Control of File Path vulnerability in the ExecuteProcessActivityCommand handler, which is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem. However, callers of the command control both the file contents AND the absolute file path on disk to which that content is written. Here’s an example of the request made to PSEMHUB. Note that, in practice, each parameter value is a form-encoded serialized Java object. For clarity, I’ve decoded and formatted it here: At [1], we see the request is being made to PSEMHUB’s central routing hub At [2], note that the request is made to the loopback address 127.0.0.1. Since this request originates from localhost, the validateClient check is satisfied At [3], the web shell contents are specified in the m_line parameter At [4], the absolute path where the contents will be written is specified in the m_targetFile parameter Looking at the handler for this request, we can see that no validation is performed to ensure that m_targetFile points to a legitimate log directory: By writing this shell to the PSEMHUB WAR path, the attacker achieves immediate remote code execution in the context of the PeopleSoft service account. Here's how those bugs look when chained together: Bug 3: PSEMHUB Deserialization of Untrusted Data (ZDI-CAN-31817) Using any file write primitive (like the ExecuteProcessActivityCommand seen above), an attacker can write a malicious XML file inside the [docroot]/envmetadata/data/environment/ directory. When the PSEMHUB HubServlet class initializes next (after a system or service restart, for example), it triggers a code flow that ultimately deserializes this XML file. Because this vector does not require writing a JSP web shell, it is less likely to be noticed by standard detection methods. Specifically, on initialization, the PSEMHUB HubServlet class calls startServerPeer in the com.peoplesoft.pt.environmentmanagement.hub.Server class: At [1], HubMBeanPersistance.getInstance() is called, which triggers the private constructor for that class At [2], env_dir_path is set to /envmetadata/data/environment/, which contains the malicious XML file placed by the attacker At [3], all files from this folder are loaded into a list variable fl At [4] and [5], the absolute path for each file in that directory is built At [6], XMLDecoder is instantiated for each file At [7], the content of the malicious XML placed by the attacker is deserialized Java's 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. Conclusion The combination of the powerful PSIGW Server-Side Request Forgery primitive alongside the decision to allow access to PSEMHUB via the loopback address by default renders the validateClient protection ineffective. Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft. The impact of SSRFs can sometimes be overlooked, especially if they have no standalone information disclosure impact. Under the right circumstances, however, the humble SSRF can open the door for complete compromise. You can find me on Twitter at @bobbygould5, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.