TrendAI’s Zero Day Initiative (ZDI) says the Oracle PeopleSoft flaw that ShinyHunters has been exploiting was three separate vulnerabilities in two components, and that Oracle fixed all of them under one identifier, CVE-2026-35273.
What ZDI reported
The breakdown comes from a ZDI blog post by researcher Bobby Gould, dated October 27. ZDI says it first reported the issue to Oracle on June 10, 2026, after an investigation by Gould with Minh Giang and Lucas Miller of TrendAI Research. The post says Mandiant released a report on September 25 about continued mass exploitation of the flaw by the ShinyHunters group.
The central point is about counting. As Gould writes, “Although Oracle issued a patch under a single CVE, we reported three distinct vulnerabilities across multiple PeopleSoft components.” ZDI says it is coordinating with Oracle to assign a separate CVE to each. At the time of the post, CVE-2026-35273 is the only identifier on the record.
Oracle’s own security alert describes one vulnerability in PeopleSoft PeopleTools. It lists versions 8.61 and 8.62 as affected, says the flaw is remotely exploitable without authentication, and says successful exploitation may result in remote code execution. Oracle writes that it considers the recommended mitigations “a high-priority risk reduction measure” and strongly recommends immediate action.
The exploitation record is longer than one campaign. In our September 29 report, drawn from Mandiant and Google Threat Intelligence Group, the group tracked as UNC6240 and identified as ShinyHunters used the flaw as a zero-day between May 27 and June 9, mostly against higher education, and then returned in a wider wave across technology, IT services, healthcare, agriculture, transportation and government. ZDI’s post adds the technical reading of what Oracle’s single patch covered, which neither Oracle’s alert nor the Mandiant reports set out.
How the three flaws fit together
ZDI describes two PeopleSoft components that run as separate web applications. The Integration Gateway exchanges messages between the PeopleSoft server and remote systems. The Environment Management Hub is an internal management interface that is meant to answer only to trusted hosts.
The first flaw is a server-side request forgery in the gateway: a request to it can steer the server’s own outbound request to a destination the sender chooses. ZDI says the hub decides whom to trust from a list of allowed hosts, and that the list ships with the local machine already on it. Combined, an outside request can arrive at the hub looking as if it came from the server itself. The other two flaws sit in the hub. One lets a caller influence where a file is written on the server, and the other processes untrusted data in a way that can run code. We are leaving out the request details ZDI published; the CVE identifier and Oracle’s alert are the references a defender needs.
Gould’s conclusion is a reminder about triage. “The impact of SSRFs can sometimes be overlooked, especially if they have no standalone information disclosure impact,” he writes. His point is that a bug that reads as moderate on its own can open a path to full compromise when it reaches an internal service that trusts local traffic.
What it means for the security leader
A single CVE hides how many separate behaviors a team has to watch for. Vulnerability dashboards, ticket queues and board reports count one item, while the engineering work behind it covers at least three. In our reading, the practical cost lands on detection engineering. ZDI says one route to code execution writes a web shell, which many detections look for. It says the second route avoids that file, and that because it “is less likely to be noticed by standard detection methods,” a team that tuned detections only to the web shell route could miss it. ZDI adds that the second route runs when the hub next starts, such as after a restart. A planted file can wait through a maintenance window before it does anything.
The history on this bug already shows the limits of perimeter rules. As we reported on September 29, Mandiant said ShinyHunters got around firewall rules that many operators put in place after June, and its advice was that WAF rules are not a substitute for patching. We made a related argument about treating a WAF rule as a patch-window control only.
The same gap shows up in exposure reporting. A scanner that checks for one identifier reports PeopleSoft as patched or unpatched, and says nothing about whether the gateway and hub are exposed to networks that have no business reaching them. Teams that keep an asset-level inventory of internet-reachable services can answer that question in minutes. Teams that track only CVE counts cannot.
The patch level question also outlasts June. Oracle’s quarterly releases, including the October Critical Patch Update with 1,295 new security patches, are separate from the June alert, so a team needs to confirm its PeopleSoft estate against both.
What defenders should do
- Apply the fix in Oracle’s security alert on PeopleTools 8.61 and 8.62. Oracle says patches under the alert program cover versions still in Premier or Extended Support and recommends planning upgrades for anything older.
- Confirm the Integration Gateway and the Environment Management Hub are not reachable from outside the network segments that need them. ZDI describes the hub as an internal interface; it should behave like one.
- Keep any firewall or proxy rule in place as a stopgap, and match it on the decoded, normalized path as Mandiant advised.
- Hunt before the next restart. Look for unexpected files in the application’s web directories and for XML files in the hub’s environment data directory that nobody on your team created. Add file integrity monitoring to both locations if it is missing.
- Update scanner and detection rules when Oracle and ZDI publish the additional CVE identifiers, and record which of the three behaviors each rule covers.
- Review any host that ran an exposed PeopleSoft instance during the exploitation window Mandiant described as compromised until proven otherwise, because a patch applied now does not remove a file written earlier.
