Oracle PeopleSoft vulnerability exploited by ShinyHunters turned out to be a chain of three separate flaws

The critical CVE-2026-35273 vulnerability in Oracle PeopleSoft Enterprise PeopleTools versions 8.61 and 8.62, which the ShinyHunters group had been exploiting as a zero-day since May 2026, is in fact not one but three separate vulnerabilities chained together. This was reported last week by the Zero Day Initiative (ZDI) team, which originally discovered the issue and disclosed it to Oracle. The vulnerability has a CVSS score of 9.8, allows an unauthenticated attacker to achieve remote code execution, and has been added to the CISA Known Exploited Vulnerabilities catalog. Organizations using PeopleSoft must immediately apply the Oracle patch released on 10 June 2026 and check for signs of compromise — installing the patch does not remove access that an attacker may have obtained earlier. We have already written about this vulnerability in the context of ShinyHunters’ claims.

Anatomy of the chain: from SSRF to code execution

Oracle closed all three flaws under a single identifier, CVE-2026-35273, but according to ZDI these are three distinct vulnerabilities across two PeopleSoft components. ZDI is coordinating with Oracle to assign a separate CVE to each flaw, but at the time of publication this single identifier is the only one in the registry. This is an important nuance: one CVE and one patch do not necessarily mean a single defect, and organizations should keep this in mind when assessing their attack surface.

Two components are involved, operating as separate web applications:

• Integration Gateway (PSIGW) — a gateway for message exchange with external systems;
• Environment Management Hub (PSEMHUB) — an internal administrative interface intended to be accessible only from trusted hosts.

According to ZDI, the exploitation chain looks as follows:

1. SSRF in PSIGW. The attacker sends a request to the Integration Gateway inbound handler and controls both the destination address and the full contents of the forwarded request. The handler does not verify whether the destination address is a legitimate target.
2. Trust check bypass via loopback. PSEMHUB determines trusted clients using a list in the allowedhosts.properties file. By default this file contains the address 127.0.0.1. The attacker directs the SSRF request to the loopback address — the request reaches PSEMHUB as if it originated from the server itself, and the trust check passes successfully. The internal interface, which Oracle intended to isolate, becomes accessible from the outside.
3. Code execution. ZDI describes two ways to turn access to PSEMHUB into arbitrary code execution. The first is via a log-writing command where the attacker controls both the contents of the file and its path on disk, allowing them to place a web shell in the application directory. The second is via writing a malicious XML file that PSEMHUB processes with Java XMLDecoder the next time the service starts, executing the attacker’s code without placing a web shell.

The second code-execution path — via XMLDecoder — is particularly dangerous in terms of detection: it does not leave any JSP files, which detection rules usually focus on. Organizations whose monitoring is limited to searching for JSP shells risk missing a compromise. Effective detection requires combining access log analysis with monitoring for processes spawned by the Java WebLogic process.

ShinyHunters campaign: from universities to government agencies

According to Mandiant and the Google Threat Intelligence Group, active exploitation of CVE-2026-35273 was observed from 27 May to 9 June 2026 — before Oracle released its patch on 10 June, which qualifies the campaign as a zero-day. The campaign has been attributed to the UNC6240 group, also known as ShinyHunters. Initially, attacks were mainly aimed at the higher education sector: by Mandiant’s estimate, 68% of the more than 100 notified organizations were universities.

In September 2026, Mandiant observed a renewed wave of mass exploitation that spread to the technology, IT services, healthcare, agriculture, transportation and government sectors. Web shells were found on dozens of systems worldwide.

The WAF bypass technique used by ShinyHunters in the second wave is noteworthy: instead of directly requesting the /PSEMHUB/ path, the attackers used URL encoding of a single character — /%50SEMHUB/. Most WAF rules perform matching against the clear-text path, whereas the PeopleSoft server decodes the path before processing it. Mandiant also notes a characteristic reconnaissance pattern: from 5 to 15 POST requests to the encoded path before exploitation begins, which can serve as an indicator in logs.

Indicators of compromise

Based on the research data, the following IOCs are available:

• File hashes:48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494, 2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7
• IP addresses: 142.11.200.186–190, 5.199.162.157, 104.219.234.138, 162.219.30.165
• Domains: azurenetfiles.net, winmanage-me.network
• C2 URL:wss://azurenetfiles.net:443/agent.ashx (MeshCentral)

Recommendations

• Apply the patch. Install Oracle’s fix for CVE-2026-35273 and make sure you are running a supported version of PeopleTools. Mandiant explicitly states that blocking paths via WAF is not a substitute for a patch — the URL-encoding technique demonstrated this clearly.
• If patching is not yet possible — disable the Environment Management Hub service in multi-server configurations or remove the PSEMHUB application in single-server setups, as Oracle recommends. This does not disrupt user sessions.
• Check for signs of compromise. Look not only for JSP web shell files, but also for suspicious XML files in PSEMHUB directories, as well as atypical child processes of the Java WebLogic process. Check logs for POST requests to URL-encoded paths (/%50SEMHUB/).
• If you detect a compromise — treat the host as fully compromised, preserve evidence, and rotate all credentials accessible from the PeopleSoft level. ShinyHunters exfiltrates data and then demands a ransom, so you should be prepared for extortion attempts.

The key architectural lesson from this incident is that including the loopback address in the trusted hosts list by default turns any SSRF vulnerability into a complete bypass of access controls for internal interfaces. For organizations running PeopleSoft, applying the patch alone is not enough — you need to ensure that there are no traces of attacker access on affected servers, since neither Oracle nor Mandiant confirm that the patch removes previously installed persistence mechanisms.