Oracle PeopleSoft Vulnerability Exploited by ShinyHunters Reveals How SSRF Can Lead to Remote Code Execution
A critical vulnerability in Oracle PeopleSoft demonstrates how attackers can turn a seemingly limited server-side request forgery (SSRF) weakness into full remote code execution by exploiting trust relationships between internal application components.
Tracked as CVE-2026-35273, the vulnerability has been associated with mass exploitation by the ShinyHunters cybercrime group. New technical research from TrendAI's Zero Day Initiative (ZDI) reveals that the underlying security problem is more complex than a single software defect, involving three distinct vulnerabilities across Oracle PeopleSoft's integration and environment management components.
The findings expose weaknesses in internal request validation, filesystem access controls, and Java object deserialization. When combined, these flaws allow attackers to bypass restrictions intended to protect administrative functionality and potentially execute malicious code with the privileges of the PeopleSoft service account.
ZDI initially reported the vulnerabilities to Oracle on June 10, 2026. Although Oracle addressed them under a single CVE identifier, researchers have requested separate identifiers to distinguish the individual security issues.
The disclosure is particularly significant because PeopleSoft is widely used to manage sensitive enterprise operations, including human resources, financial processes, and institutional administration. A compromise of its underlying application infrastructure can therefore expose organizations to risks extending beyond a single web service.
Three Vulnerabilities Hidden Behind One CVE
According to ZDI researcher Bobby Gould, the investigation uncovered three separate weaknesses involving two PeopleSoft components deployed as Oracle WebLogic applications.
The first component, PeopleSoft Integration Gateway (PSIGW), facilitates communication between PeopleSoft and external systems. It processes incoming messages and routes them through connectors that support different integration protocols.
The second component, PeopleSoft Environment Management Hub (PSEMHUB), provides internal environment management functionality. Because these operations can affect the application environment, PeopleSoft includes a validateClient mechanism intended to restrict access to trusted hosts.
The researchers identified the following vulnerabilities:
ZDI-CAN-31816 — Server-Side Request Forgery: An attacker can abuse the Integration Gateway's HTTP connector to direct requests toward internal services, including endpoints that would otherwise be inaccessible.
ZDI-CAN-31818 — External Control of File Path: A PSEMHUB command allows callers to influence both the contents and absolute destination path of files written to the server, creating an opportunity to place executable content in sensitive locations.
ZDI-CAN-31817 — Deserialization of Untrusted Data: A separate PSEMHUB code path processes XML files using Java's
XMLDecoder, potentially executing attacker-controlled operations during object reconstruction.
Each weakness affects a different security boundary. The SSRF provides access to protected functionality, while the file-writing and deserialization vulnerabilities create alternative routes toward code execution.
The distinction is important because fixing only one visible symptom may leave related weaknesses in place. It also complicates vulnerability management when several technically different defects are grouped under a single CVE.
ZDI has stated that it is coordinating with Oracle to obtain separate identifiers for the three reported issues.
The SSRF Vulnerability Defeats PeopleSoft's Trusted-Host Protection
The attack begins with PeopleSoft Integration Gateway's handling of HTTP requests.
The gateway includes an HttpListeningConnector that receives inbound HTTP messages and forwards them through a selected target connector. In the vulnerable implementation, attackers can influence the destination URL and the data transmitted to that destination.
The security weakness arises because the connector does not adequately validate whether the requested destination is legitimate.
This gives an attacker the ability to make the PeopleSoft server issue HTTP requests on the attacker's behalf.
That behavior is the defining characteristic of server-side request forgery. Instead of connecting directly to a restricted internal service, the attacker persuades an accessible application component to make the connection.
In the PeopleSoft exploitation chain, the target is PSEMHUB, whose administrative endpoints are protected by a trusted-host validation mechanism.
The validateClient method checks the hostname and IP address of incoming clients against entries stored in an allowedhosts.properties configuration file.
By default, the trusted-host list includes the loopback interface, which represents requests originating from the local machine.
That default is reasonable for internal administrative services, but it creates a problem when another component on the same server can be manipulated into sending arbitrary requests.
The vulnerable Integration Gateway can forward attacker-controlled requests to the loopback address, causing PSEMHUB to perceive them as originating from a trusted local client.
Consequently, the request passes the validateClient check even though its contents originated with an external attacker.
The result is a trust-boundary failure: a service designed to accept requests only from trusted hosts becomes accessible through a separate application component that does not enforce equivalent restrictions.
This is why the SSRF vulnerability is so consequential. Its immediate capability is to redirect server-side requests, but its practical impact depends on the sensitive functionality available at the destination.
In this case, the destination exposes additional vulnerabilities capable of escalating the attack to remote code execution.
Arbitrary File Writing Creates a Direct Path to Code Execution
Once attackers can reach PSEMHUB through the SSRF vulnerability, they can exploit a second weakness in its ExecuteProcessActivityCommand handler.
The handler supports functionality for writing log information to the PeopleSoft server's filesystem.
Under normal circumstances, such functionality should restrict file operations to approved directories and prevent callers from selecting arbitrary destinations.
However, ZDI found that the vulnerable implementation allows callers to control both the content being written and the absolute filesystem path where it will be stored.
The application does not adequately verify that the destination belongs to a legitimate logging directory.
This creates an arbitrary file-writing primitive, subject to the filesystem permissions available to the PeopleSoft process.
An attacker who can write executable server-side content into an accessible application directory may subsequently cause the server to process that content.
ZDI demonstrated how this weakness could be used to place a malicious JSP web shell inside the PSEMHUB web application.
A web shell is a server-side script that allows an attacker to execute commands or perform other unauthorized operations through HTTP requests.
Because the content executes within the application server environment, the resulting access operates with the permissions of the PeopleSoft service account.
This is a substantial escalation from the initial SSRF weakness.
The attacker is no longer limited to making the server contact internal endpoints. The combination of vulnerabilities can provide the ability to execute commands on the affected system.
The practical consequences depend on the privileges assigned to the service account and the security controls surrounding the application server.
Potential outcomes include unauthorized access to application files, modification of deployed components, theft of accessible configuration data, and further activity within the compromised environment.
The research does not establish that every affected deployment would provide unrestricted operating system privileges. Nevertheless, code execution within a sensitive enterprise application server represents a serious security incident.
Unsafe XML Deserialization Offers an Alternative Exploitation Route
The third vulnerability provides a different path to code execution and may be less conspicuous than deploying a conventional web shell.
ZDI discovered that PSEMHUB loads XML files from an environment metadata directory during initialization.
The affected code uses Java's XMLDecoder to reconstruct objects from the stored XML content.
Unlike a simple XML parser that extracts data values, XMLDecoder can instantiate objects and invoke methods as part of its reconstruction process.
This behavior becomes dangerous when the application processes XML files that an attacker can create or modify.
The researchers found that an attacker with a suitable file-writing capability could place malicious XML in the environment metadata directory.
When the relevant PSEMHUB initialization sequence runs, such as following a service or system restart, the application processes the malicious file.
The attacker-controlled operations can execute during deserialization, before the application reaches a subsequent type conversion that may fail.
This detail matters because an exception occurring after deserialization does not necessarily prevent the malicious behavior. The dangerous operations may already have taken place.
The exploitation chain therefore has two potential routes to code execution.
The first involves writing a JSP web shell into the application deployment directory and invoking it through the web server.
The second involves writing malicious XML into the environment metadata directory and waiting for the affected initialization process to deserialize it.
The second approach may avoid some detection mechanisms focused specifically on newly created JSP files or suspicious web shell activity.
However, it has an additional operational condition: the relevant initialization path must execute before the malicious XML is processed.
Both techniques depend on the ability to write files into locations accessible to the PeopleSoft service account.
ShinyHunters Exploitation Raises the Stakes
The technical findings are especially concerning because CVE-2026-35273 has been linked to active exploitation by ShinyHunters.
In September 2026, Google's Mandiant published research describing continued mass exploitation of the vulnerability by the cybercrime group.
The ZDI analysis, published in October, explains how weaknesses in PeopleSoft's integration and environment management components can be combined to achieve a much more serious outcome than SSRF alone might suggest.
The distinction between the two reports is important.
Mandiant's investigation provides the threat intelligence context surrounding exploitation activity, while ZDI's research examines the underlying implementation weaknesses and explains the technical exploitation paths.
The existence of a demonstrated attack chain does not establish that every intrusion attributed to ShinyHunters used every technique described by ZDI.
Attackers may select different exploitation methods depending on the environment, available privileges, and operational objectives.
Nevertheless, the combination of active exploitation reports and detailed technical disclosure substantially increases the urgency of remediation.
For organizations running PeopleSoft, the issue should be treated as an actively relevant enterprise security threat rather than a purely theoretical software weakness.
Why SSRF Vulnerabilities Are Often Underestimated
Server-side request forgery is sometimes perceived as less serious than vulnerabilities that directly permit command execution.
That assessment can be misleading when an affected application has access to privileged internal services.
In modern enterprise environments, application servers frequently communicate with databases, management interfaces, metadata services, authentication systems, and other components that are not intended to be accessible from untrusted networks.
An SSRF vulnerability can allow attackers to cross those boundaries indirectly.
The PeopleSoft case is a particularly clear example because the protected service explicitly trusts requests originating from localhost.
The security control evaluates where the immediate HTTP connection appears to originate, rather than whether the request was initiated by an authorized actor.
When the Integration Gateway forwards a malicious request through the loopback interface, the protected component accepts it as local traffic.
The problem is therefore not simply that an attacker can control a URL. It is that the application treats network origin as sufficient evidence of authorization.
This design assumption becomes unsafe when another reachable component can be used to generate requests from a trusted location.
The subsequent file-writing and deserialization vulnerabilities amplify the consequences, transforming access to internal functionality into the possibility of arbitrary code execution.
The broader lesson extends beyond PeopleSoft. Internal services should not assume that traffic originating from localhost or a trusted network is necessarily authorized.
Strong authentication, explicit authorization checks, and restrictions on server-side outbound requests are essential for preserving security boundaries.
What PeopleSoft Administrators Should Prioritize
Organizations operating Oracle PeopleSoft should review their exposure to CVE-2026-35273 and verify that the applicable Oracle security corrections have been installed.
Because the attack involves multiple components and distinct implementation weaknesses, remediation should address the vendor's complete security guidance rather than focusing only on the SSRF behavior.
Recommended actions include:
Apply Oracle's security updates. Identify affected PeopleSoft components and deploy the vendor-provided corrections through established change-management procedures.
Restrict access to integration endpoints. Ensure that PeopleSoft Integration Gateway services are reachable only by authorized systems and users where operationally possible.
Review internal service exposure. Limit unnecessary access to PSEMHUB and other administrative interfaces, including access originating from application servers.
Monitor unexpected file modifications. Investigate newly created JSP files, changes to application deployment directories, and suspicious modifications to environment metadata.
Inspect application server activity. Review WebLogic and PeopleSoft logs for unusual requests, unexpected outbound connections, and unexplained execution activity.
Assess service account privileges. Ensure PeopleSoft processes operate with only the filesystem and operating system permissions required for their intended functions.
Investigate potential compromise. Where exploitation is suspected, examine application files, configuration changes, credentials, and related systems rather than assuming that patch installation alone removes an existing foothold.
Administrators should also evaluate whether vulnerable services have been exposed to untrusted networks or reachable from other systems that may already be compromised.
Network segmentation can reduce the number of possible attack paths, but it should not be treated as a substitute for correcting the underlying vulnerabilities.
Where a web shell or unauthorized application modification is discovered, incident response should include an assessment of the affected service account and any credentials accessible to the compromised process.
A Trust Boundary Failure With Enterprise-Wide Consequences
The Oracle PeopleSoft findings demonstrate how several individually distinct security weaknesses can combine into a serious compromise of enterprise application infrastructure.
The initial SSRF vulnerability allows attackers to redirect requests through a trusted application component. That access defeats PSEMHUB's localhost-based validation mechanism and exposes functionality that was intended to remain restricted.
From there, insufficient filesystem path validation provides a route to writing executable server-side content, while unsafe XML deserialization offers an alternative path that can execute attacker-controlled operations during application initialization.
The resulting attack chain illustrates a recurring failure in complex enterprise software: security controls designed around individual components may be ineffective when attackers exploit interactions between those components.
The connection to ShinyHunters activity makes the disclosure particularly relevant for organizations relying on PeopleSoft to support sensitive business operations.
CVE-2026-35273 is not merely an SSRF vulnerability. It represents a chain of trust-boundary and input-handling failures capable of turning access to an integration service into remote code execution.
For defenders, the priority is to apply Oracle's corrections, investigate potential exposure, and ensure that internal management functionality cannot be accessed solely because a request appears to originate from a trusted host.
The case reinforces a fundamental security principle: internal network location should never substitute for explicit authorization, particularly when the surrounding application architecture allows requests to be forwarded between services.