CVE-2026-35273 is the kind of enterprise vulnerability that deserves substantially more attention than its CVSS score alone suggests.
Oracle disclosed the vulnerability in June 2026 as a critical flaw affecting the Updates Environment Management component of Oracle PeopleSoft Enterprise PeopleTools. Supported PeopleTools versions 8.61 and 8.62 are affected. Oracle states that the vulnerability is remotely exploitable without authentication and that successful exploitation may lead to remote code execution. Its CVSS v3.1 score is 9.8, with network attack vector, low attack complexity, no privileges required, no user interaction, and high confidentiality, integrity, and availability impact. (Oracle)
That alone would make CVE-2026-35273 an emergency patching candidate.
The actual story is considerably worse.
Google’s Mandiant and Google Threat Intelligence Group subsequently disclosed that activity consistent with exploitation of CVE-2026-35273 had already been observed between May 27 and June 9, 2026, before Oracle released its June 10 security alert. Google attributed the campaign to UNC6240, also known as ShinyHunters, and reported notifying more than 100 organizations whose infrastructure appeared potentially exposed. Sixty-eight percent of those organizations operated in higher education. (Google Cloud)
CISA also added CVE-2026-35273 to its Known Exploited Vulnerabilities context, and the NVD record identifies it as CWE-306: Missing Authentication for Critical Function while noting active exploitation and total technical impact in CISA’s SSVC data. (NVD)
More importantly for defenders, vulnerability research released after Oracle’s advisory suggests that CVE-2026-35273 should not be understood merely as “a vulnerable HTTP endpoint that executes commands.”
The exploitation surface involves PeopleSoft’s Environment Management infrastructure and multiple powerful application behaviors. ZDI separately documented an unauthenticated SSRF condition in HttpListeningConnector, an unsafe deserialization condition in HubMBeanPersistance, and a path-control weakness in ExecuteProcessActivityCommand. These weaknesses can be chained across PeopleSoft’s administrative infrastructure to cross authentication boundaries and ultimately execute code in the context of the PeopleSoft service account. (Zero Day Initiative)
That explains why Oracle’s risk matrix uses unusually strong language: successful exploitation can result in takeover of PeopleSoft Enterprise PeopleTools. (Oracle)
CVE-2026-35273 at a Glance
| Attribut | Détails |
|---|---|
| CVE | CVE-2026-35273 |
| Vendor | Oracle |
| Produit | PeopleSoft Enterprise PeopleTools |
| Composant | Updates Environment Management |
| Affected supported versions | PeopleTools 8.61 and 8.62 |
| Vecteur d'attaque | Réseau |
| Authentication required | Non |
| User interaction | Aucun |
| Attack complexity | Faible |
| CVSS v3.1 | 9.8 Critical |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Impact primaire | Remote code execution and PeopleTools takeover |
| Relevant attack surface | PSEMHUB / Environment Management and Integration Broker |
| Exploited in the wild | Oui |
| Zero-day exploitation observed | Oui |
| Public campaign attribution | UNC6240 / ShinyHunters |
| CISA KEV relevance | Oui |
| Vendor remediation | Oracle security update / June 2026 security update guidance |
Oracle’s original advisory is unusually direct: an unauthenticated attacker with network access over HTTP can compromise PeopleSoft Enterprise PeopleTools, and successful exploitation may produce remote code execution. Oracle also notes that when HTTP is listed as an affected protocol, secure variants such as HTTPS should be considered affected as well. HTTPS therefore does pas remove the vulnerability; TLS protects transport, not vulnerable application behavior. (Oracle)
Why the PeopleSoft Environment Management Framework Matters
To understand why CVE-2026-35273 can become a full takeover problem, defenders need to understand what the vulnerable PeopleSoft infrastructure actually does.
PeopleSoft’s Environment Management Framework, or EMF, is not merely a monitoring dashboard.
Oracle describes EMF as a set of software elements used to gather and publish PeopleSoft installation, configuration, and update information. It can identify file servers, web servers, application servers, hosts, and Process Scheduler systems that make up a PeopleSoft environment.
Critically, Oracle also documents that EMF provides a mechanism for carrying out commands remotely on machines in the PeopleSoft environment as directed by Change Assistant. (Oracle Documentation)
Its principal components include:
- Environment Management Hub —
PSEMHUB - Environment Management Agent —
PSEMAgent - Environment Management Viewer
The hub is effectively a broker between these peers.
Oracle documentation explains that the Environment Management Hub maintains configuration information, registers peers, monitors agent health, and brokers messages between systems. Agents deployed across managed PeopleSoft infrastructure communicate with the hub and can receive actions associated with environment administration and software deployment. (Oracle Documentation)
That architectural context changes the threat model.
A vulnerability in an ordinary informational web page might expose data belonging to that page.
A vulnerability in an infrastructure component designed to understand machines, exchange administrative messages, manage deployment information, and participate in remote execution workflows can provide access to something much closer to a control plane.
Conceptually:
Internet
|
v
PeopleSoft Web Tier
|
+--> PeopleSoft Internet Architecture
|
+--> PSIGW
| |
| +--> HttpListeningConnector
|
+--> PSEMHUB
|
+--> Environment Management Hub
|
+--> Environment Metadata
+--> Managed Hosts
+--> PSEMAgent
+--> Update / Deployment Operations
+--> Administrative Commands
This is one of the main reasons organizations should not evaluate CVE-2026-35273 as though it were simply a vulnerability in the PeopleSoft login interface.
It targets infrastructure that was intentionally designed to communicate with other trusted components.
PSEMHUB Is an Administrative Component, Not a Normal User Page
Oracle’s documentation lists PSEMHUB as one of the PeopleSoft servlets residing on the web server.
The standard portal servlet handles normal browser-facing PeopleSoft interactions. PSIGW, meanwhile, acts as a gateway for service requests and responses between PeopleSoft nodes and external systems. PSEMHUB supports Environment Management Framework functionality used by lifecycle-management tools such as Change Assistant. (Oracle Documentation)
A typical Environment Management Agent configuration contains a hub URL resembling:
http://hostname:port/PSEMHUB/hub
Oracle documents that agents use this endpoint to communicate with the hub. (Oracle Documentation)
This endpoint later became highly significant in real-world CVE-2026-35273 investigations.
Mandiant specifically advised organizations to search PIA WebLogic access logs for externally sourced:
POST /PSEMHUB/hub
and:
POST /PSIGW/HttpListeningConnector
requests. (Google Cloud)
That is an important detection clue because external interaction with administrative PeopleSoft components often deserves much greater scrutiny than an ordinary request to a user-facing PeopleSoft portal.
CVE-2026-35273 Is Better Understood as an Exploit Chain
Oracle’s public CVE description abstracts CVE-2026-35273 into a single critical vulnerability.
The research disclosed by TrendAI’s Zero Day Initiative provides significantly more technical resolution.
At least three ZDI advisories are associated with CVE-2026-35273:
| ZDI Advisory | Vulnerable Area | Security Primitive |
|---|---|---|
| ZDI-26-387 | HttpListeningConnector | Server-Side Request Forgery |
| ZDI-26-388 | HubMBeanPersistance | Deserialization of untrusted data |
| ZDI-26-389 | ExecuteProcessActivityCommand | External control of file path leading to RCE |
This distinction matters.
The vulnerability is not necessarily best modeled as:
HTTP request
|
v
Runtime.exec(attacker_command)
A more useful defender-oriented model is:
Unauthenticated External Attacker
|
v
Externally reachable PeopleSoft interface
|
v
SSRF / trust-boundary bypass
|
v
Reach privileged internal PeopleSoft functionality
|
v
Unsafe data-processing / administrative primitive
|
v
File or object manipulation
|
v
Code Execution
|
v
PeopleSoft service-account access
|
v
PeopleTools takeover
The distinction also explains why edge-layer protections alone should not be treated as complete remediation.
Stage One: HttpListeningConnector and SSRF
ZDI-26-387 identifies a flaw inside the PeopleSoft HttpListeningConnector class.
According to ZDI, insufficient validation of a URI allows an unauthenticated remote attacker to make arbitrary server-side requests. ZDI explicitly states that the SSRF behavior can be combined with other vulnerabilities to execute arbitrary code in the context of the service account. (Zero Day Initiative)
The PeopleSoft HTTP Listening Connector is a real, documented integration mechanism rather than an obscure unused function.
Oracle documents its standard URL as:
http://gatewayserver/PSIGW/HttpListeningConnector
The connector is implemented as a Java servlet and processes incoming PeopleSoft Integration Broker messages. It accepts a variety of message parameters and can consume values from request metadata, headers, query strings, and message bodies. (Oracle Documentation)
In a secure architecture, an Internet user should not be able to use such functionality as a generic mechanism for instructing the server to contact arbitrary resources.
An SSRF vulnerability changes that trust relationship.
Instead of the topology being:
Attacker ---> Public PeopleSoft Endpoint
it can become conceptually:
Attacker
|
v
Public PeopleSoft Endpoint
|
| server-side request
v
127.0.0.1 / internal service / trusted management interface
The critical observation is that internal application endpoints often make security assumptions based on where a connection originates.
If a service trusts localhost, an internal subnet, or another PeopleSoft component, SSRF may transform an externally untrusted attacker into an apparently trusted server-side caller.
That is why SSRF is frequently much more dangerous in enterprise control-plane software than in an isolated consumer web application.
Stage Two: Unsafe Deserialization in HubMBeanPersistance
A second ZDI advisory, ZDI-26-388, documents a flaw in HubMBeanPersistance.
According to ZDI, the method fails to properly validate user-supplied data and can consequently deserialize untrusted input. Exploitation can result in arbitrary code execution in the context of the service account. ZDI notes that authentication would ordinarily be required for this portion of the attack surface, but that the authentication mechanism can be bypassed. (Zero Day Initiative)
Java deserialization vulnerabilities have a long history of producing serious server compromises because deserialization is not equivalent to parsing inert JSON.
A simplified conceptual example illustrates the difference.
Safe application logic tries to transform data into explicitly permitted structures:
Config config = parseValidatedConfiguration(input);
Dangerous native object deserialization can instead reconstruct object graphs:
ObjectInputStream stream =
new ObjectInputStream(request.getInputStream());
Object object = stream.readObject();
If attacker-controlled objects reach a dangerous deserialization mechanism and appropriate classes or invocation paths are available in the application’s runtime, unexpected code paths can execute during reconstruction.
The exact CVE-2026-35273 exploit does not need to be reproduced in production to understand the defensive conclusion:
An authentication or network trust boundary stands between an attacker and a dangerous object-processing primitive. If another vulnerability removes that boundary, the severity of the primitive changes dramatically.
This is why treating the SSRF and deserialization findings as independent low-level bugs can underestimate their combined impact.
Stage Three: ExecuteProcessActivityCommand
ZDI-26-389 provides another piece.
La vulnérabilité existe dans le ExecuteProcessActivityCommand class. ZDI states that the software does not sufficiently validate a user-supplied path before using that path in file operations. The condition can be leveraged for arbitrary code execution in the context of the PeopleSoft service account. (Zero Day Initiative)
Again, ZDI describes authentication as ordinarily required but bypassable.
That creates a powerful compositional security problem:
External user
|
| no legitimate PeopleSoft credentials
v
Authentication boundary
|
| bypassed by earlier primitive
v
Administrative functionality
|
| improperly controlled attacker input
v
Filesystem / execution primitive
|
v
RCE
This is precisely why security engineers should think in terms of reachable attack graphs, not merely individual CVSS scores.
A vulnerability requiring authentication can effectively become pre-authentication if another vulnerability reliably provides a way around the authentication boundary.
Why Oracle Rates CVE-2026-35273 at CVSS 9.8
Oracle’s vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Breaking that down:
| Métrique | Valeur | Signification |
|---|---|---|
| AV | Réseau | Exploitable remotely |
| AC | Faible | No unusual race or complex prerequisite is required |
| PR | Aucun | No authenticated account is required |
| UI | Aucun | No victim action is required |
| S | Unchanged | Impact remains within the vulnerable security authority |
| C | Haut | Major confidentiality impact |
| I | Haut | Major integrity impact |
| A | Haut | Major availability impact |
The combination is close to the worst profile possible for an enterprise server vulnerability.
There is no phishing step.
There is no requirement for an administrator to open a malicious document.
There is no requirement for compromised PeopleSoft credentials.
The critical prerequisite is essentially network reachability to vulnerable functionality.
For Internet-exposed deployments, that drastically compresses the attacker’s path from discovery to exploitation.
From RCE to PeopleTools Takeover
“Remote code execution” and “takeover” are sometimes used interchangeably in vulnerability reporting, but they are worth separating.
RCE means an attacker obtains the ability to cause code to execute on the vulnerable system.
The privilege and security context of that code determines what happens next.
ZDI states that the relevant flaws may execute code in the context of the PeopleSoft service account. (Zero Day Initiative)
From there, an attacker can begin post-exploitation.
Potentially valuable information on a PeopleSoft server can include:
PeopleSoft configuration
Application server configuration
WebLogic configuration
Environment metadata
Database connectivity details
Integration settings
Filesystem paths
Internal hostnames
Process Scheduler configuration
Service credentials or secrets accessible to the service account
SSH material
Network-mounted filesystems
The real-world ShinyHunters campaign provides an unusually useful demonstration.
Google found command histories showing attackers inspecting psappsrv.cfg, querying mount information, examining /etc/hosts, and reading WebLogic config.xml files after compromise. (Google Cloud)
That sequence should look familiar to any incident responder:
Initial Access
|
v
RCE on PeopleSoft
|
v
Host Discovery
|
v
Application Configuration Discovery
|
v
Credential / Trust Relationship Discovery
|
v
Internal Network Mapping
|
v
Lateral Movement
|
v
Collection
|
v
Exfiltration
This is the practical meaning behind “takeover.”
The vulnerability is not valuable to an attacker merely because it executes id or creates a proof file.
It creates an entry point into an enterprise application environment that often contains highly sensitive HR, payroll, financial, identity, student, government, or organizational data.
CVE-2026-35273 Was Exploited as a Zero-Day
The timeline is central to understanding the incident.
Oracle’s public security alert was dated June 10, 2026.
Mandiant reports observing associated malicious activity beginning on May 27, 2026, continuing through June 9. That places exploitation roughly two weeks ahead of public remediation. (Google Cloud)
A simplified timeline looks like this:
May 27, 2026
|
| Observed malicious infrastructure / activity begins
v
Late May – Early June
|
| PeopleSoft systems targeted
| PSEMHUB-related activity
| Compromise and internal reconnaissance
v
June 9
|
| Stolen victim information appears on
| ShinyHunters leak infrastructure
v
June 10
|
| Oracle releases emergency Security Alert
| CVE-2026-35273 remediation becomes available
v
June 11
|
| Mandiant publishes campaign findings
v
June 12
|
| CVE appears in KEV context
v
June 24
|
| ZDI publishes deeper technical advisories
v
This timeline changes remediation strategy.
For a newly disclosed vulnerability with no exploitation evidence, an organization might patch and consider the incident closed.
That approach is insufficient here.
Because exploitation preceded patch availability, patching cannot prove that a system was never compromised.
Organizations with vulnerable systems exposed during the zero-day window should treat patching and compromise assessment as two separate requirements.
The ShinyHunters PeopleSoft Campaign
Google attributed the campaign to UNC6240, which it associates with ShinyHunters.
The threat activity was financially motivated and focused on compromise, data theft, lateral movement, and extortion rather than simply exploiting machines for cryptomining or adding them to a botnet. (Google Cloud)
Google notified more than 100 organizations associated with potentially vulnerable infrastructure. Most were in the United States, and 68% were universities or colleges.
Some organizations successfully blocked or remediated the activity.
Others were compromised, and stolen data later appeared on the ShinyHunters data-leak site. (Google Cloud)
This is significant because higher-education PeopleSoft environments can contain an unusually broad combination of sensitive information:
- student information,
- employee records,
- payroll information,
- financial records,
- identity data,
- administrative account information,
- institutional operational data.
Consequently, a PeopleSoft compromise can quickly transform from a technical infrastructure incident into a major data-breach and extortion event.
What the Attackers Did After Initial Compromise
Mandiant’s investigation benefited from an unusual operational mistake by the attackers.
Several staging servers exposed directory listings, allowing investigators to inspect attacker tooling and command history.
The staging systems included customized MeshCentral agents. MeshCentral is legitimate open-source remote-management software, but attackers configured agents to connect back to their infrastructure. The binaries used names such as:
meshagent32-azure-ops.exe
meshagent64-azure-ops.exe
meshagent64-v2.exe
Mandiant found them configured to communicate with:
wss://azurenetfiles.net:443/agent.ashx
The domain imitated legitimate Microsoft Azure-related terminology. (Google Cloud)
This is a useful defensive lesson.
Post-exploitation malware does not always look like bespoke malware.
Attackers increasingly use legitimate administrative or remote-management software because those tools already provide:
- remote shell capabilities,
- process execution,
- file transfer,
- persistence,
- cross-platform management,
- encrypted command-and-control communication.
Detection therefore needs behavioral context rather than merely traditional malware signatures.
PeopleSoft Reconnaissance After RCE
The command history uncovered by Mandiant shows attackers mapping PeopleSoft infrastructure after compromise.
Among the artifacts examined were the Process Scheduler configuration file:
psappsrv.cfg
and WebLogic:
config.xml
They also inspected mounted filesystems and local hosts information. (Google Cloud)
The objective is straightforward.
Once inside one PeopleSoft server, an attacker wants to answer:
What system did I compromise?
What other PeopleSoft machines exist?
Where is the application server?
Where is the Process Scheduler?
What network shares are mounted?
Which internal hosts are trusted?
Which credentials or service relationships can I reuse?
What databases and internal services can this server reach?
This represents the transition from application exploitation à enterprise intrusion.
For defenders, that means incident-response scope should not end with the web-tier server.
Mouvement latéral
Google also observed a propagation script designed to move through PeopleSoft-associated systems over SSH.
The attackers parsed locally available host information, attempted authentication against additional internal systems, and propagated an extortion/defacement marker to PeopleSoft directories. (Google Cloud)
The important defensive point is not the exact script.
It is the trust relationship it exploited.
Enterprise applications frequently span multiple machines:
Web Tier
|
Application Server
|
Process Scheduler
|
Database
|
File / Report Servers
Operational convenience sometimes leads to reused service accounts, shared administrative passwords, broad SSH trust, mounted network filesystems, or permissive east-west network policies.
An Internet-facing RCE turns these internal conveniences into attacker acceleration mechanisms.
Segmentation therefore matters even after CVE-2026-35273 has been patched.
Data Exfiltration
Mandiant observed attackers compressing stolen data using zstd before exfiltration and connecting toward infrastructure associated with the ShinyHunters data-leak operation. (Google Cloud)
For SOC teams, the combination of these behaviors creates useful retrospective hunting opportunities:
PeopleSoft web exploitation
+
unexpected child processes
+
reconnaissance against PeopleSoft config
+
SSH activity
+
archive creation
+
unexpected remote-management agent
+
external C2
An individual event may appear benign.
The sequence is not.
Why CVE-2026-35273 Is Not Just an Authentication Bypass
The NVD/CISA classification of CWE-306 — Missing Authentication for Critical Function — captures an important aspect of the vulnerability. (NVD)
But defenders should avoid interpreting the bug as:
“An attacker can log in without a password.”
That mental model is too narrow.
The dangerous outcome is not necessarily an attacker receiving an ordinary PeopleSoft UI session.
Instead, authentication and trust controls protecting backend functionality can be bypassed, exposing powerful management behavior.
The distinction is:
Traditional authentication bypass
Attacker
|
v
Login Boundary
|
v
Authenticated User Session
versus:
CVE-2026-35273-style attack path
Attacker
|
v
Backend Integration / Management Surface
|
v
Trust Boundary Bypass
|
v
Privileged Internal Functionality
|
v
RCE
The second is often significantly more dangerous because the attacker may never need an ordinary application account at all.
The Role of /PSIGW/HttpListeningConnector
PeopleSoft Integration Broker uses the HTTP Listening Connector for inbound integration messages.
Oracle describes it as a Java servlet accepting incoming HTTP messages and supporting several mechanisms for carrying message metadata. (Oracle Documentation)
The documented endpoint is:
/PSIGW/HttpListeningConnector
This endpoint is therefore not automatically malicious.
Legitimate integrations may use it.
Detection must consider:
Source
+
method
+
request metadata
+
destination behavior
+
internal addressing
+
timing
+
subsequent host behavior
Mandiant specifically recommends looking for requests to this endpoint containing loopback references such as:
127.0.0.1
localhost
::1
or private/internal IP ranges in parameters or headers. Such values can indicate attempts to leverage SSRF to reach resources inaccessible directly from the Internet. (Google Cloud)
Safe Exposure Validation
Because CVE-2026-35273 is known to have been exploited in the wild, production validation should focus first on determining exposure and patch state, rather than immediately attempting to reproduce RCE.
A basic authorized exposure test can verify whether sensitive paths are externally reachable without attempting exploitation.
Par exemple :
curl -sk -o /dev/null \
-w "%{http_code}\n" \
https://people.example.com/PSEMHUB/hub
and:
curl -sk -o /dev/null \
-w "%{http_code}\n" \
https://people.example.com/PSIGW/HttpListeningConnector
The purpose of these requests is only to determine routing and exposure.
A 403, 404ou 200 by itself does pas conclusively determine vulnerability status. Reverse proxies, authentication middleware, custom PeopleSoft deployments, WebLogic configuration, redirects, and security devices can all affect responses.
The authoritative question remains:
Is the affected PeopleTools installation patched according to Oracle’s CVE-2026-35273 guidance?
Do not infer safety purely because a signature-based scanner fails to reproduce an exploit.
A Small Defensive Exposure Checker
Security teams managing multiple authorized PeopleSoft instances can perform non-destructive reachability checks using a simple script:
import requests
target = "https://people.example.com"
paths = [
"/PSEMHUB/hub",
"/PSIGW/HttpListeningConnector",
]
for path in paths:
url = target.rstrip("/") + path
try:
response = requests.get(
url,
timeout=10,
allow_redirects=False,
verify=True,
)
print(
f"{url} -> "
f"HTTP {response.status_code} "
f"length={len(response.content)}"
)
except requests.RequestException as exc:
print(f"{url} -> error: {exc}")
This is not a CVE-2026-35273 exploit detector.
It answers a narrower but operationally valuable question:
Can an untrusted network currently reach PeopleSoft management or integration endpoints that should probably be tightly restricted?
Actual vulnerability confirmation should be correlated with PeopleTools version, Oracle patch inventory, configuration, and maintenance records.
Hunt for External Requests to PSEMHUB
Google recommends reviewing PIA WebLogic access logs for external requests to:
POST /PSEMHUB/hub
particularly requests originating from untrusted addresses. (Google Cloud)
A generic log-hunting workflow might begin with:
grep -R 'POST /PSEMHUB/hub' /path/to/weblogic/logs/
Then narrow by source address and time period.
Similarly:
grep -R 'POST /PSIGW/HttpListeningConnector' /path/to/weblogic/logs/
The primary questions are:
Did the source come from an expected integration partner?
Was it internal or external?
Did the request occur before patching?
Did the host create unexpected files afterward?
Did the host initiate unusual outbound traffic afterward?
Did new processes appear around the same timestamp?
A suspicious HTTP event becomes far more valuable when correlated with endpoint and network telemetry.
Hunt for SSRF Indicators
Pour HttpListeningConnector traffic, defenders should identify requests containing references to:
127.0.0.1
localhost
::1
as well as RFC1918 addressing:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
These values are not universally malicious, especially in integration-heavy environments.
But externally initiated requests instructing an application gateway to communicate with loopback or internal systems deserve immediate investigation.
Conceptually:
External Source IP
|
v
HttpListeningConnector
|
+---- destination = localhost
|
+---- destination = private address
|
v
HIGH-SIGNAL SSRF CANDIDATE
Hunt the PSEMHUB Filesystem
Mandiant recommends inspecting the PeopleSoft web tier for unexpected JSP files beneath the PSEMHUB application.
One relevant location is conceptually:
<PS_CFG_HOME>/
webserv/
<domain>/
applications/
peoplesoft/
PSEMHUB.war/
Unexpected .jsp files deserve close examination. (Google Cloud)
Par exemple :
find "$PS_CFG_HOME" \
-path '*PSEMHUB*' \
-type f \
-name '*.jsp' \
-print
Do not simply delete suspicious files when performing incident response.
Preserve:
timestamps
hashes
ownership
permissions
surrounding logs
process history
filesystem metadata
before remediation whenever possible.
A webshell may be the most visible artifact of compromise, but deleting it does not remove credentials, persistence, backdoors, or lateral access already established elsewhere.
Inspect Environment Metadata and Transaction Directories
Mandiant additionally recommends reviewing:
PSEMHUB.war/envmetadata/transactions/
for unexpected files or directories.
Unexpected directories named:
logs
persistantstorage
scratchpad
under PSEMHUB-related paths may also warrant investigation. (Google Cloud)
Organizations should baseline these directories on clean systems.
File-integrity monitoring becomes dramatically more useful when analysts know exactly which files belong to a standard PeopleTools deployment.
XMLDecoder Persistence
Another particularly interesting recommendation from Google’s investigation is reviewing:
<docroot>/envmetadata/data/environment/
for recently created or modified XML files.
Mandiant warns that such files may potentially be abused to achieve code execution via XMLDecoder during an application restart. (Google Cloud)
This creates an incident-response trap.
Suppose defenders:
- discover the vulnerability,
- install the patch,
- restart PeopleSoft,
- assume the server is clean.
If an attacker already planted persistence material before remediation, the restart may interact with previously written malicious state.
Therefore:
PATCHED != NEVER COMPROMISED
and:
PATCHED != CLEAN
This distinction is essential for every exploited zero-day.
Monitor Outbound SMB
Google specifically recommends monitoring PeopleSoft systems for outbound SMB traffic over TCP/445 toward untrusted external destinations. (Google Cloud)
Why would a PeopleSoft server initiate Internet SMB?
Potential SSRF chains can sometimes be used to coerce Windows-backed infrastructure into authenticating toward attacker-controlled systems, exposing NTLM authentication material.
Even without reproducing a specific exploitation technique, the detection principle is straightforward:
PeopleSoft server
|
| outbound TCP/445
v
Internet host
should be extremely unusual in most environments.
At the firewall or network-detection layer:
source_role = PeopleSoft
destination = Internet
destination_port = 445
action = attempted/allowed
should generally be treated as a high-priority event.
Where business requirements permit, outbound SMB from application servers should be blocked entirely.
Indicators Observed in the ShinyHunters Campaign
Google published multiple campaign-related indicators, including staging infrastructure in the 142.11.200.x range and the domain:
azurenetfiles.net
Mandiant also identified several staged MeshCentral agent hashes and filenames. (Google Cloud)
Voici quelques exemples :
meshagent64-azure-ops.exe
meshagent32-azure-ops.exe
meshagent64-v2.exe
meshagent
and the extortion marker:
README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT
as well as an organization-specific propagation script matching the pattern:
[victim_abbreviation]_fanout.sh
These indicators are useful, but organizations should avoid designing detection around IOCs alone.
Infrastructure and filenames are easy for attackers to change.
Behavioral detection around PSEMHUB exploitation, unusual JSP writes, PeopleSoft configuration discovery, remote-management tooling, SSH propagation, and archive creation will remain useful longer.
A Practical Detection Matrix
| Couche | What to Hunt |
|---|---|
| Web access | External POST requests to /PSEMHUB/hub |
| Integration gateway | Suspicious /PSIGW/HttpListeningConnector demandes |
| SSRF | Loopback/private destination references |
| Filesystem | Unexpected JSP files beneath PSEMHUB |
| Environment metadata | Unexpected transaction/staging content |
| XML | Recently modified environment XML files |
| Réseau | External SMB/445 from PeopleSoft servers |
| Endpoint | Unknown Java child processes or shell execution |
| Administration | Unexpected MeshCentral agents |
| Discovery | Reads of psappsrv.cfg, WebLogic config.xml, /etc/hosts |
| Lateral movement | Abnormal SSH authentication attempts |
| Collection | Unexpected large archives, including zstd activity |
| C2 | Connections to known campaign infrastructure |
Detection should prioritize correlations rather than one isolated signature.
Par exemple :
External POST to PSEMHUB
+
new JSP file
+
shell process
+
read psappsrv.cfg
+
outbound SSH
is substantially stronger evidence than any one event alone.
Immediate Mitigation
The first remediation priority is Oracle’s official update.
Oracle strongly recommends immediate action and states that customers should remain on actively supported versions and apply Critical Patch Updates, Critical Security Patch Updates, and Security Alerts without delay. Oracle’s June 2026 patch guidance also states that the PeopleSoft security update incorporates remediation for the alert. (Oracle)
Organizations should obtain the exact patch applicable to their deployment through Oracle’s support infrastructure rather than relying on an unofficial “fixed version” claim.
This distinction matters because enterprise Oracle vulnerabilities are frequently resolved through patch bundles or maintenance updates rather than through an obvious product-version jump.
Do not assume:
8.61 = vulnerable
8.62 = vulnerable
8.63 = automatically the required fix
unless Oracle’s specific patch documentation for the environment supports that conclusion.
Disable Environment Management Hub When Possible
Google’s remediation guidance recommends disabling the Environment Management Hub service in multi-server configurations when operationally possible.
In single-server environments, it recommends removing the PSEMHUB application according to Oracle’s security-alert guidance. (Google Cloud)
This mitigation is particularly compelling because Oracle itself documents that Environment Management Framework is optional for many Change Assistant workflows and required primarily for particular environment discovery/file deployment functions. (Oracle Documentation)
The general security principle is:
If an administrative application is not required continuously, do not expose it continuously.
Restrict /PSEMHUB/*
If EMHub cannot be disabled, restrict access to:
/PSEMHUB/*
and especially:
/PSEMHUB/hub
to trusted management networks and expected peers.
The intended architecture is closer to:
Internet
|
X
|
PSEMHUB
Management Network
|
+--------> PSEMHUB
than:
Internet
|
+--------> PSEMHUB
Mandiant characterizes restricting these administrative endpoints as generally non-breaking for normal end-user PeopleSoft PIA browser sessions. (Google Cloud)
Restrict HttpListeningConnector
Similarly, external access to:
/PSIGW/HttpListeningConnector
should be limited to systems that genuinely need to communicate with the PeopleSoft Integration Broker.
If an organization has known integration partners, allowlisting is substantially stronger than making the connector universally Internet reachable.
Par exemple :
Internet
|
+--- arbitrary source --------X
|
Trusted Integration Partner
|
+---------------------------> PSIGW
Network architecture should enforce the intended trust relationship rather than relying solely on application code to distinguish trusted from untrusted callers.
Do Not Treat a WAF as the Patch
A Web Application Firewall can be useful as a temporary containment layer.
It is not equivalent to remediation.
Google specifically warns against relying solely on WAF body-inspection rules because such controls may be bypassed. (Google Cloud)
This distinction is particularly important for SSRF and multi-stage application exploits.
A signature might attempt to detect:
127.0.0.1
but alternative addressing representations, internal DNS names, parser differences, encoding behavior, redirect chains, alternate fields, and application-specific transformations can make simplistic string rules fragile.
A stronger temporary strategy is:
Block untrusted access to the vulnerable endpoint
rather than:
Allow everyone, but try to recognize malicious payloads.
Patch and Then Perform Incident Response
For CVE-2026-35273, a good remediation workflow should look more like:
Identify
|
v
Contain
|
v
Patch
|
v
Hunt
|
v
Scope
|
v
Eradicate
|
v
Rotate Credentials
|
v
Restore Trust
|
v
Monitor
rather than:
Patch
|
v
Done
This follows directly from the zero-day timeline.
Systems exposed between at least May 27 and the organization’s patch date should be considered candidates for compromise assessment. (Google Cloud)
Credential Rotation May Be Necessary
If an investigation finds evidence that attackers executed code in the PeopleSoft service-account context, defenders should evaluate credentials accessible from that account.
That includes not only an interactive password but also potentially:
application credentials
database credentials
integration secrets
API secrets
keystores
SSH keys
mounted-share credentials
service identities
configuration-file secrets
A common incident-response failure is to remove malware without invalidating credentials acquired during compromise.
If stolen credentials remain valid, the vulnerability can be patched while the attacker retains access through an entirely different channel.
Review East-West Segmentation
The observed campaign demonstrates why segmentation matters.
A compromised PeopleSoft web-tier server should not automatically have unrestricted administrative access to every other PeopleSoft node.
Organizations should document and enforce flows between:
Web tier
Application tier
Process Scheduler
Database
Integration Broker
File services
Administrative management hosts
A good architecture might permit only the minimum required service relationships:
Internet
|
Reverse Proxy
|
PeopleSoft Web Tier
|
restricted flows
v
Application Tier
|
restricted DB connection
v
Database
Administrative protocols such as SSH and SMB should have especially narrow policies.
Reduce Public Administrative Surface
CVE-2026-35273 provides a broader lesson for enterprise software security.
The external application footprint that users need is often much smaller than the external footprint created by a default installation.
PeopleSoft can expose several classes of functionality:
User portal
Integration endpoints
Management endpoints
Update infrastructure
Monitoring functions
Administrative services
They do not all need the same accessibility.
A useful external-attack-surface review should answer:
Which PeopleSoft paths are reachable from the Internet?
Which are required for human users?
Which exist only for system integration?
Which are management-only?
Which can be placed behind VPN or private connectivity?
Which can be disabled entirely?
The answer can eliminate entire classes of future vulnerability before a patch exists.
Why Unsupported PeopleTools Releases Are Also a Concern
Oracle’s public advisory lists supported affected releases as PeopleTools 8.61 and 8.62.
However, Oracle also explicitly notes that unsupported product versions are not necessarily tested for the vulnerabilities addressed by security alerts and that earlier versions may also be affected. Oracle recommends upgrading to supported releases. (Oracle)
Therefore:
Not listed as affected
does not necessarily mean:
tested and confirmed safe
for an obsolete PeopleTools branch.
Organizations running unsupported releases should not assume immunity simply because the security matrix only names currently supported versions.
Why HTTPS Does Not Protect Against CVE-2026-35273
Another likely misconception is:
“Our PeopleSoft system is HTTPS-only, so the HTTP vulnerability does not apply.”
Oracle explicitly addresses this issue in its advisory.
When the Oracle risk matrix specifies HTTP as the affected protocol, secure variants such as HTTPS are implied unless otherwise stated. (Oracle)
TLS provides:
Confidentiality in transit
Server authentication
Transport integrity
It does not repair:
Missing application authentication
SSRF
Unsafe deserialization
Path validation flaws
Authorization mistakes
Therefore:
HTTPS + vulnerable application
is still:
vulnerable application
Why CVE-2026-35273 Is Particularly Attractive to Attackers
From an attacker economics perspective, this vulnerability has nearly every desirable property:
Network reachable
+
No credentials
+
No user interaction
+
Low attack complexity
+
Enterprise software
+
High-value data
+
Powerful administrative infrastructure
+
Potential service-account code execution
Compare it with a client-side vulnerability:
Find user
→ send payload
→ persuade user
→ trigger vulnerable application
→ escape sandbox
→ establish persistence
CVE-2026-35273 can dramatically reduce that process:
Find exposed PeopleSoft
→ reach vulnerable management surface
→ exploit
→ obtain server-side execution
This asymmetry is why KEV-listed perimeter RCE vulnerabilities tend to have disproportionate defensive priority.
CVE-2026-35273 vs. a Conventional Vulnerability Scanner Finding
Traditional scanners might report:
Oracle PeopleSoft version detected
CVE-2026-35273 may apply
CVSS: 9.8
That is useful for inventory.
It is not the full security question.
A deeper assessment asks:
Is PSEMHUB reachable?
Is PSIGW reachable?
From which networks?
Can an untrusted source cross the expected authentication boundary?
What patch level is actually installed?
Are there signs of historical exploitation?
Did the server communicate externally during the zero-day period?
Were unexpected JSP or XML files written?
Did the PeopleSoft service identity perform abnormal actions?
This difference between vulnerability identification et attack-path validation is particularly important for agentic security testing and human-led penetration testing.
A checkbox saying “CVE detected” cannot establish whether a real attacker already traversed the chain.
Defensive Validation Without Weaponizing the Vulnerability
For authorized security teams, an appropriate validation methodology can be organized into four levels.
Level 1: Inventory Validation
Determine:
PeopleTools release
patch level
Oracle security-alert installation status
WebLogic topology
internet exposure
Level 2: Endpoint Exposure
Check whether:
/PSEMHUB/hub
/PSIGW/HttpListeningConnector
are externally reachable.
Do not send deserialization payloads or invoke execution primitives merely to establish exposure.
Level 3: Trust-Boundary Validation
Verify firewall and proxy behavior.
Can arbitrary Internet sources communicate with administrative paths?
Can only expected agents and integration partners access them?
Is external SMB blocked?
Level 4: Post-Compromise Hunting
Révision :
WebLogic access logs
PeopleSoft logs
filesystem events
JSP files
XML metadata
shell execution
process trees
SSH activity
SMB activity
DNS telemetry
proxy logs
remote management software
archive creation
credential use
This produces significantly more useful risk evidence than attempting a destructive production exploit.
Related PeopleSoft Security Context
CVE-2026-35273 was not the only serious PeopleTools vulnerability disclosed in the same security period.
Oracle’s June 2026 PeopleSoft risk matrix also included additional high-severity flaws affecting components such as Deployment Package, Application Server, and Performance Monitor. Some were remotely exploitable without authentication, including takeover-class issues. (Oracle)
That should influence remediation strategy.
Do not treat CVE-2026-35273 as an isolated patching exercise while leaving the surrounding PeopleTools stack months behind on Critical Patch Updates.
Enterprise application security benefits from cumulative patch hygiene because attack chains frequently combine apparently separate vulnerabilities.
Frequently Asked Questions
Is CVE-2026-35273 remotely exploitable?
Yes.
Oracle explicitly classifies it as remotely exploitable over a network without authentication. (Oracle)
Does an attacker need a PeopleSoft username or password?
No legitimate PeopleSoft account is required for the overall vulnerability described by Oracle.
The CVSS vector is PR:N, and Oracle calls it remotely exploitable without authentication. ZDI’s component-level analysis indicates that some deeper functionality ordinarily expects authentication, but that boundary can be bypassed as part of the vulnerability chain. (Oracle)
L'interaction avec l'utilisateur est-elle nécessaire ?
No.
The CVSS vector contains:
UI:N
No employee needs to click a link or open a file.
Can CVE-2026-35273 lead to remote code execution?
Yes.
Oracle explicitly states that successful exploitation may result in remote code execution. ZDI separately documents code-execution primitives associated with the CVE. (Oracle)
Can it lead to full PeopleTools takeover?
Yes.
Oracle’s risk matrix states that successful attacks can result in takeover of PeopleSoft Enterprise PeopleTools. (Oracle)
That should not automatically be interpreted as instant administrative control over every connected enterprise system. Lateral movement into databases, other hosts, identity systems, or unrelated applications still depends on the target environment and post-exploitation opportunities.
Which PeopleTools releases are affected?
Oracle identifies supported versions:
8.61
8.62
as affected. (Oracle)
Oracle also cautions that unsupported releases are not necessarily tested and that earlier versions may also be vulnerable.
Is PeopleTools 8.63 definitely the required fix?
Do not use that assumption as your remediation strategy.
Oracle’s advisory directs customers to the appropriate patch availability documentation. Confirm the exact supported patch level for your deployment through Oracle rather than inferring safety from the major/minor version number alone.
Is CVE-2026-35273 exploited in the wild?
Yes.
Mandiant and Google Threat Intelligence Group observed activity consistent with exploitation from May 27 through June 9, 2026, before Oracle’s advisory became public. (Google Cloud)
Who exploited it?
Google attributes the documented campaign to UNC6240, associated with ShinyHunters. (Google Cloud)
Was it a zero-day?
Yes, in the context of the campaign documented by Google.
Observed exploitation preceded Oracle’s June 10 advisory.
Is PSEMHUB itself malicious?
No.
PSEMHUB is a legitimate PeopleSoft Environment Management component.
Oracle documents it as part of the Environment Management Framework used by PeopleSoft lifecycle-management tooling. (Oracle Documentation)
The security problem is exposing vulnerable functionality to attackers, not the existence of PSEMHUB itself.
Should PSEMHUB be Internet accessible?
For most environments, sensitive administrative infrastructure should be restricted as tightly as operational requirements permit.
Mandiant recommends disabling EMHub where possible or blocking untrusted external access to /PSEMHUB/* when it cannot be disabled. (Google Cloud)
Is blocking /PSEMHUB/* enough?
It is a valuable mitigation but should not replace Oracle’s patch.
A complete response should include patching, exposure reduction, log review, host investigation, and compromise assessment.
Can a WAF completely mitigate the vulnerability?
It should not be assumed to.
Google specifically warns that relying solely on WAF body-inspection rules is insufficient because they can potentially be bypassed. (Google Cloud)
Should organizations investigate old logs after patching?
Yes.
Because exploitation occurred before the public patch, systems exposed during the zero-day period may have been compromised before remediation.
Review historical telemetry beginning at least around the publicly documented exploitation window of May 27, 2026, and extend the hunt earlier where retention permits.
Final Assessment
CVE-2026-35273 deserves to be treated as one of the more serious Oracle PeopleSoft vulnerabilities of 2026 because all of the conditions that normally slow an attacker are largely absent.
It is remotely reachable.
It requires no legitimate user account.
It requires no victim interaction.
Oracle rates exploitation complexity as low.
The vulnerable surface sits inside the PeopleSoft Environment Management architecture, where systems already possess trusted relationships with other components.
ZDI’s later technical disclosures show how an unauthenticated SSRF condition, unsafe deserialization behavior, and dangerous file/execution functionality can contribute to a larger exploit path rather than merely producing an isolated application error. (Zero Day Initiative)
And this is no longer a hypothetical risk.
Mandiant observed attackers associated with ShinyHunters targeting PeopleSoft infrastructure before Oracle’s security advisory existed, followed by system reconnaissance, remote-management deployment, lateral movement, collection, data theft, and extortion activity. (Google Cloud)
The resulting defensive priority is clear:
Patch immediately
+
remove unnecessary Internet exposure
+
restrict PSEMHUB and PSIGW
+
review the zero-day exposure window
+
hunt for compromise
+
investigate filesystem persistence
+
review outbound SMB and C2
+
rotate exposed credentials
+
segment PeopleSoft infrastructure
For CVE-2026-35273, installing the update addresses the vulnerability.
C'est le cas pas, by itself, answer the more important incident-response question:
Was the PeopleSoft environment already compromised before the patch was installed?
Organizations that had externally reachable PeopleTools 8.61 or 8.62 infrastructure during the exploitation window should answer both questions—not just the first one. (Oracle)
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew