ZDI says Oracle's PeopleSoft CVE-2026-35273 covers three separate bugs, and Oracle's alert names one component

Three ZDI advisories name one CVE, and the scores differ

On 24 June 2026 the Zero Day Initiative (ZDI) published three advisories, ZDI-26-387, ZDI-26-388 and ZDI-26-389. All three list the same identifier, CVE-2026-35273, and carry three different scores: 9.3, 7.5 and 8.8. Oracle's own record for that identifier carries a fourth, 9.8, and names one component. On 27 October, 125 days after the advisories (derived), a ZDI blog said that although Oracle issued a patch under a single CVE, the team reported three distinct vulnerabilities across multiple PeopleSoft components, and that it is coordinating with Oracle to assign separate CVEs. Read from 21:19 UTC on 28 October 2026.

This is the PeopleSoft flaw that Mandiant says UNC6240, which it identifies as ShinyHunters, exploited as a zero day from 27 May to 9 June and again in September. The earlier briefing on the encoded path that beat a firewall rule covers that account, and this one does not repeat it. What is new is how the flaw is decomposed, how the decomposition lines up with what Mandiant published, and what it means for anyone who closed a ticket on the one identifier. Claims that ShinyHunters makes about its own victims stay claims here.

ZDI is TrendAI's vulnerability research programme, and its site lists researcher rewards; TrendAI sells security products. Oracle sells PeopleSoft and wrote the alert. Mandiant, part of Google, sells incident response. Each has an interest in how this is told, and each is attributed below.

What this does not establish

It does not establish that Oracle's patch leaves any of the three open. Each ZDI advisory says Oracle has issued an update to correct the vulnerability. The blog describes the chain in the present tense and never says what Oracle changed, so the record does not tell a reader whether the chain still works on a patched system. It also does not say the patch closes all three.

It does not establish which of the three bugs Mandiant saw used. Mandiant's June post tells defenders to look for request forgery on the gateway path, but neither of its posts says which flaws were used, and ZDI's chain figure labels its attacker ShinyHunters while the text frames it as how an attacker "like" the group can combine the bugs, not as an observed intrusion.

It does not establish how many organisations were affected. Mandiant says web shells were deployed on dozens of systems in the September wave and gives no count, and ZDI gives none. It does not establish that a new CVE has been assigned: none was found in the records read (see below). And ZDI's blog does not say when Oracle introduced the validateClient check, so any claim that it arrived with the June patch is not supported by the page.

The three bugs, in ZDI's own terms

ZDI's blog numbers the bugs one to three, and its advisory numbers run in a different order: bug 2 is ZDI-26-389 and bug 3 is ZDI-26-388. The table follows the blog's numbering and gives the advisory beside it. Scores and vectors are as ZDI printed them; ZDI does not print a CWE number for any of the three.

ZDI's advisories for bugs 2 and 3 say authentication is required but that the existing authentication mechanism can be bypassed. The blog explains the bypass: the first bug makes the request come from inside, and the check lets the server's own loopback address through. Bug 1 is scored on its own as an unauthenticated request forgery with high confidentiality and low integrity impact and nothing on availability, so none of the three, scored alone, has Oracle's vector of unauthenticated full takeover. Our reading: Oracle's 9.8 describes what the chain achieves, and ZDI's scores describe the links. Neither primary says so.

Zoom

Zoom

An allowlist that trusts the server itself is a name, not a control

ZDI describes PSEMHUB, the Environment Management Hub, as an internal management interface that implements a validateClient method so that only trusted clients can reach it. The method builds a path to a file called allowedhosts.properties, loads the hostnames and addresses in it, and returns true if the requesting host is in the list. ZDI prints the shipped default file as holding a localhost entry, and says the list the check builds also holds the server's own resolved hostname and address.

That is where the friendly name does the work of a control. A check described as restricting access to trusted clients sounds like a boundary. It is a boundary only if nobody untrusted can make a trusted client speak for them, and ZDI says the gateway's handler in the same product does no validation that the traffic is legitimate or bound for a valid target. ZDI's wording is that because Oracle allows localhost by default, the request forgery provides exactly the access the check wants. ZDI's closing observation is that a request forgery with no standalone disclosure impact can be overlooked, and that under the right circumstances it opens the door to complete compromise.

Zoom

How the three bugs line up with what Mandiant published (our reading)

The earlier briefing carried Mandiant's September account of the %50SEMHUB path trick. Mandiant's two posts, of 11 June and 25 September, never say that the flaw is three bugs and never name a handler or a bug class. But their defender advice names the places where the three bugs live. The table sets each item beside the ZDI bug it appears to match. Every mapping in the right hand column is this site's reading, and the third column says why it is only that.

There is a tension the record leaves open. Mandiant says that before exploiting, targeted servers received five to fifteen POST requests to the hub path and that unpatched servers answered with the host operating system. Mandiant's hunting advice looks for such requests from external source addresses. ZDI's figure says a direct call from the internet to the hub is blocked by validateClient because the external address is not on the list. Both can be true only if the check was not enforcing for those servers, or if the observed requests did not take the route ZDI draws. Neither primary addresses it, and this site does not know which it is.

One more date is worth the arithmetic. Mandiant's 11 June post already told defenders to watch the gateway path for loopback values and the environment directory for XML files, 138 days before ZDI's blog (derived). Read with hindsight, the advice covered all three places. What the posts did not do is tell a reader that these were three flaws with their own fix questions.

Zoom

What Oracle's one patch does and does not settle on the record

The table sets what each primary says about the patch beside what it leaves unsaid. The negative column is the point: the fix question is open on the evidence available without an Oracle support login.

On new identifiers: a search of NVD for PeopleTools records published from 11 June to 28 October returned 122 records. Oracle's October 2026 Critical Patch Update of 20 October added four lower scored records in Updates Environment Mgmt (2.5 to 6.0) and two in Integration Broker (4.7 and 7.1). None is credited to TrendAI in that update's credit statement, whose only ZDI credit is for five Outside In records, and Oracle's descriptions never name a bug class. This site does not link any of them to ZDI's three, and no primary does. ZDI's own words, on 27 October, are that the coordination is still under way.

Two small oddities for the record. The ZDI blog's web address contains 2026/10/20, but the page itself and its metadata give 27 October 2026, and this briefing uses 27 October. And Oracle's credit statement lists three people at TrendAI against the one CVE, the same number that ZDI's advisories credit.

What it means for patching, as inference

Everything in this section is this site's inference from the sources above, not a statement by any of them.

One identifier is one ticket, and the ticket may be wider than it looks. A scanner, a KEV feed and a change record all key on CVE-2026-35273. If Oracle later assigns two more identifiers, an estate that closed the one has no record of whether the other two were covered, and the date it closed it may be the only evidence it has. The control that tells a reader whether the June patch covers all three is Oracle's patch documentation, not the identifier.

A control built around one bug can miss the others. A rule or a hunt written for external requests to /PSEMHUB/ has nothing to see in ZDI's chain at the step that matters, because that request arrives from the server itself. Mandiant's June advice named both paths. Its September hunting advice names only the hub path, although its September remediation text does say the Environment Management Hub and the Integration Broker listening connector are administrative components and that restricting them from the public internet does not break normal user sessions.

Removing localhost trust is not something the primaries tell a reader to do. ZDI prints the shipped default and describes the consequence. Neither ZDI nor Oracle's alert says that the entry can be safely removed, and a PeopleSoft estate that edits the file without Oracle's guidance risks affecting the hub's own working, which is an inference and not a documented fact. Ask Oracle, in writing, before changing it.

Technical details

The artifacts below are the ones the primaries print, copied as printed, with the date read. None is a working exploit. ZDI's blog prints request and handler snippets as images and in descriptions of them; this section lists the names and paths, not a request a reader could replay, and it leaves out the content of the written file. Neither ZDI nor Oracle prints a detection query or rule for the three bugs. Mandiant says Google Security Operations rules exist, among them one named Oracle PeopleSoft Configuration Inspection and, pending in its September post, Oracle PeopleSoft Suspicious File Write to Web Application Archive Directory.

Names and paths from the ZDI blog. They are what a defender can search for in decompiled code, access logs and on disk. The two parameter names are the ones ZDI says carry the file content and the target path in the PSEMHUB request.

/PSIGW/HttpListeningConnector
HttpTargetConnector
validateClient
/envmetadata/config/allowedhosts.properties
ExecuteProcessActivityCommand
m_line
m_targetFile
[docroot]/envmetadata/data/environment/
com.peoplesoft.pt.environmentmanagement.hub.Server
startServerPeer
HubMBeanPersistance
XMLDecoder

ZDI's score and vector for each advisory, copied from the three advisory pages.

ZDI-26-387 ZDI-CAN-31816 CVE-2026-35273 9.3 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
ZDI-26-389 ZDI-CAN-31818 CVE-2026-35273 8.8 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
ZDI-26-388 ZDI-CAN-31817 CVE-2026-35273 7.5 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Oracle's risk matrix row for the single CVE, set out one field per line. The vector is the one in the NVD and CVE.org records.

CVE-2026-35273
PeopleSoft Enterprise PeopleTools
Updates Environment Management
HTTP
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
8.61, 8.62

Mandiant's 11 June hunting guidance, which names the gateway path, the loopback check and the XML directory. Run these against the PIA WebLogic access logs and the web tier filesystem.

POST /PSEMHUB/hub
POST /PSIGW/HttpListeningConnector
127.0.0.1, localhost, ::1
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/
.../PSEMHUB.war/envmetadata/transactions/
logs, persistantstorage, scratchpad
<docroot>/envmetadata/data/environment/

Mandiant's September indicators. The path pattern is the encoded spelling; Mandiant says to assume any percent encoded, mixed case or otherwise non normalised variant and to enforce blocking on the normalised path. Addresses are defanged.

/%50SEMHUB/
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/x.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/u.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/Ple64.exe
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jspx
5[.]199[.]162[.]157
104[.]219[.]234[.]138
162[.]219[.]30[.]165
winmanage-me[.]network
48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494 x.jsp
2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7 u.jsp
419c571ee38b7e7266d130c4b6bbc4dd0ef44d6e5f3bc02cc2cf73b762f07c86 tunnel.jsp
ba14419beb2ec0bb94cab6298c14d7fb3e1d819366fe378290c0c2a4d97f7e07 tunnel.jspx
3ba215692665513abfffd4e815c5c45f2d41e5dcc4283a2a3b740930c5c417c3 Ple64.exe

Mandiant notes that the x.jsp hash varies because of extra newline characters, and that the tunnel hashes vary with the key used, so file names and locations matter more than the hashes.

What to do, in order

What was read, and what was not

Read in full and saved: the ZDI blog; the three ZDI advisories 387, 388 and 389 and the published advisories list; Oracle's Security Alert; Oracle's July and October Critical Patch Updates (credit statements, and the PeopleTools rows in October); the NVD and CVE.org records and the CISA catalog entry; and Mandiant's posts of 11 June and 25 September. The ZDI blog was fetched again before finishing and had not changed.

Not read: The Register's account of the ZDI blog, because its robots.txt disallows crawlers it does not name and this site's research agent identifies itself honestly; the Oracle Patch Availability Document, which sits on Oracle's support portal; and Mandiant's indicator collection for registered users. No source here is a secondary one.

The question this leaves

A ticket says CVE-2026-35273 is closed. ZDI says that identifier stands for three bugs in two components, reported to Oracle together on one date, and that Oracle's patch carried one label for them. The label closed. Nothing on the public record says what the patch did to the gateway, the file write or the XML read, or whether the allowlist still trusts the server that forwards the request.

So the question for your own estate: which of the three code paths does your ticket close, and who told you so in writing?

Key facts