Analysis of CVE-2026-35273: Oracle PeopleSoft PeopleTools Server Side Request Forgery

CVE-2026-35273 is a serious vulnerability affecting Oracle PeopleSoft PeopleTools. It involves a server-side request forgery weakness that allows an attacker to make the PeopleSoft system send requests internally, including to sensitive components that are not normally exposed to outside users.

The still active exploitation from UNC6240 (ShinyHunters) (as stated by Mandiant and Google Threat Intelligence Group (GTIG) on June 11) led the Fortra Intelligence and Research Experts (FIRE) team to conduct an analysis of the vulnerability in context to develop the exploit for Core Impact.

From the details provided in the previous blogpost, CISA catalog, and Oracle’s advisory, it can be inferred that the endpoint that was attacked was /PSIGW/HttpListeningConnector.

A quick search on the internet showed the operation of that endpoint and led us to a very basic payload for the vulnerability:

<IBRequest>
  <ExternalOperationName>PoC for CVE-2026-35273</ExternalOperationName>
  <OperationType>Sync</OperationType>
   <Connector>
     <ConnectorClassName>HttpTargetConnector</ConnectorClassName>
      <ConnectorParameters>
         <ConnectorParam>
           <Name>URL</Name>
           <Value><![CDATA[http://localhost:8000/PSEMHUB/hub?OPERATION=VGVzdE9wZXJhdGlvbg]]></Value>
         </ConnectorParam>
         <ConnectorParam>
           <Name>Method</Name>
           <Value>POST</Value>
         </ConnectorParam>
      </ConnectorParameters>
   </Connector>   
   <ContentSection>
      <Data>
      <![CDATA[Fortra FIRE]]>
      </Data>
   </ContentSection>
</IBRequest>

In this image, you can see it working:

Image

The response is a base64 encoded serialized Java string object with the text: Invalid Operation specified.

A search in the decompiled sources of PSEMHUB.war leads to com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#processInvalidOperation:

Image

This is being called by com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#doPost:

Image

Among all the allowed operations, the HANDLE_MESSAGE operation (which has a value of 3 returned by com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#getOperation) stands up. The operation is handled by com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#processHandleMessage.

Image

In the code, we can see that the function expects 3 parameters: MESSAGE, UUID_ARRAY and HEARTBEAT_INTERVAL.

All 3 parameters are decoded using the com.peoplesoft.pt.environmentmanagement.HTTP.HTTPEncodeDecodeUtils#base64DecodeAndReincarnateObject function:

Image

This function decodes the parameter from base64 and the uses com.peoplesoft.pt.environmentmanagement.utils.EMObjectInputStream#EMObjectInputStream to deserialize a Java object.

Now, this class implements a whitelist approach for deserialization, allowing only certain classes:

Image

After reviewing the source code of the list of available classes, a very simple and interesting class emerged: com.peoplesoft.pt.changeassistant.commands.ExecuteProcessActivityCommand:

Image

The important part here is the execute method. This method will be executed when the Message is processed by the peer’s queue.

This method will create the file given by the m_targetFile attribute (if the file exists, it will open in append mode). Then it will save (or add) the contents of the m_line attribute inside. For this to happen, the m_isStdOutput attribute must be True.

So, we could serialize this class inside a Message to write a file with arbitrary content in an arbitrary location.

Now, going back to processHandleMessage method, when the parameters are processed and the objects are deserialized, the com.peoplesoft.pt.environmentmanagement.hub.Server#handleMessage method is called.

This method is long, but the first important part is the following:

Image

At the beginning, the method extracts the source and the target from the Message object.

Then performs a check to see if this message is of type com.peoplesoft.pt.changeassistant.commands.ExecuteProcessCommand.

Since this class allows the execution of OS system commands, the method will not execute if the peer type receiving the message is not “ChangeAssistant.” Since we are on the Hub, the type does not start with “ChangeAssistant.”

Then the method performs several validations that can be easily bypassed or ignored and reaches an important part:

Image

Here, we see that if the target name equals the name of the Hub (which is "com.peoplesoft.emf:name=server,type=Server"), then the message is added to the Hub queue.

Another important thing to notice is in the final part of the image: the method saves in queueSource the values from the m_queues Hashtable. But, if we only send a Message, this returns null. So, another step must be made previously to the Message: peer registration.

For completeness, com.peoplesoft.pt.environmentmanagement.hub.Server#getName is defined as the following:

Image

So, if we “register a peer” against the hub and send a Message with a serialized ExecuteProcessActivityCommand object inside, we could write a JSP web shell in the hub and get unauthenticated remote code execution.

The peer registration is made using the REGISTER_WITH_PEERNAME operation (which has a value of 1 returned by com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#getOperation)

The com.peoplesoft.pt.environmentmanagement.HTTP.HubServlet#processRegisterWithPeerName function has a lot of parameters, but it’s very straightforward:

Image

It requires 8 parameters (PING_IN_MS, PEERNAME, INRECONNECT, PEERTYPE, HUBURL, HOSTNAME, PEERPORT, VERSION) and ends up calling the com.peoplesoft.pt.environmentmanagement.hub.Server#register(int, java.lang.String, boolean, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String) function. The analysis of this function exceeds the scope of this blog post. The only thing we need to know is that for this function to succeed, we only need to pass valid arguments.

From the image, the (Java) type of argument can be deducted. And the values can be the following:

• PING_IN_MS = Numeric value in milliseconds (5000)
• PEERNAME = String value ("FortraExploitPeer")
• INRECONNECT = Boolean value (False)
• PEERTYPE = String value ("AGENT")
• HUBURL = String value (""http://localhost:8000/PSEMHUB/hub"") - Here "localhost" is better than "127.0.0.1"
• HOSTNAME = String value ("localhost")
• PEERPORT = String value of the TCP port (“8000”)
• VERSION = String value ("Version: 8.62.03 Build Number: ")

So, in summary, the server-side request forgery vulnerability can be abused with the following steps:

1. Send a GET HTTP request to the /PSEMHUB/hub endpoint with a payload that sets the SSRF to use the REGISTER_WITH_PEERNAME operation along with the required 8 parameters that we described before.
   This will return a base64 encoded Java string object with a peer ID in the form “com.peoplesoft.emf:name=XX” where XX is a numeric value.
2. Send a second GET HTTP request to the /PSEMHUB/hub endpoint with a payload that sets the SSRF to use the HANDLE_MESSAGE operation along with the required 3 parameters.
   The Message object must contain a serialized ExecuteProcessActivityCommand object in the _command attribute. Also, its _messageSourceObjectName attribute must be set to the obtained peer ID in the previous step and its _messageDestinationObjectName attribute set to “com.peoplesoft.emf:name=server,type=Server” to target the Hub.
   The serialized ExecuteProcessActivityCommand object must have its m_isStdOutput attribute set to True to write (or add) the contents of the m_line attribute in the file given by the m_targetFile attribute.
   The return of this request will be a base64 encoded java object with the NULL value.

In practical terms, this means an attacker may be able to move from simply reaching the vulnerable PeopleSoft endpoint to gaining control over the affected application server. That level of access could lead to data theft, system compromise, persistence, or further movement inside the organization’s network.

Organizations using Oracle PeopleSoft should review Oracle’s advisory, apply the relevant patches or mitigations immediately, and investigate whether the affected endpoints have been exposed or accessed suspiciously. Particular attention should be given to PeopleSoft gateway and hub endpoints, unusual internal requests, unexpected peer registrations, and suspicious files written to web-accessible directories.