Summary

CVE–2026–35273 is an actively exploited, unauthenticated remote code execution vulnerability in Oracle PeopleSoft Enterprise PeopleTools — not a routine critical–CVE patch. Oracle disclosed it on June 10, 2026 in an out–of–band Security Alert, rating it CVSS 9.8 and placing it in the Updates Environment Management component. Oracle states successful exploitation may result in remote code execution; NVD describes possible takeover of PeopleSoft Enterprise PeopleTools. Reaching sensitive data or moving internally still requires post–exploitation activity. 

This was a zero–day with a pre–patch window, not a freshly introduced bug. Based on the details from external sources the exploitation traces are consistent with CVE–2026–35273 to as early as May 27, 2026 — roughly two weeks before Oracle’s June 10 disclosure — in a compromise and extortion campaign it attributes to UNC6240/ShinyHunters. 

CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on June 12, 2026, with a June 15, 2026 remediation due date. For PeopleTools 8.61 and 8.62 environments, that is a clear prioritization signal. It should not be inflated into claims of broad compromise: external sources notified more than 100 organizations with potentially vulnerable endpoints — most in the United States, 68% in higher education — but a notification is not a confirmed breach, and no precise victim count has been published. Oracle’s own advisory does not explicitly state exploitation; external sources and KEV status carry that finding. 

Who Is Exposed

The vulnerability lives in PeopleSoft management surfaces where the Environment Management Hub remains reachable. Oracle confirms supported PeopleTools versions 8.61 and 8.62 as affected, states PeopleSoft Enterprise Applications customers may also be affected, and notes that earlier, unsupported releases are untested but likely affected. 

The version list identifies where to investigate — it does not prove exploitability. Real exposure is configuration–dependent. The highest–risk profile combines: 

• PeopleTools 8.61 or 8.62 in use 
• The Environment Management Hub (EMHub/PSEMHUB) enabled and reachable 
• The Integration Broker HTTP listening connector (PSIGW/HttpListeningConnector) reachable 
• Network reachability to those paths — directly, or through a reverse proxy, WAF, load balancer, VPN route, cloud ingress, or partner connectivity 
• No confirmed patch or mitigation in place

Treat this as configuration–aware exposure validation, not patch–counting alone. 

What to Hunt For After Initial Access

An unauthenticated request to a reachable PSEMHUB or PSIGW path can hand an attacker code execution on the web tier. 

External reporting attributes the observed campaign to UNC6240/ShinyHunters; some early reporting preserved the possibility of an impersonator, so treat attribution as  high–confidence assessment from external entity rather than settled fact. In this threat activity the chain of actions by threat actors was observed as follows, operators staged customized MeshCentral agents masquerading as Azure–related services and communicating with the doamin azurenetfiles.net, inspected PeopleSoft and WebLogic configuration, mapped internal hosts, moved over SSH, ran a [victim_abbreviation]_fanout.sh propagation script, and dropped extortion markers. MeshCentral is legitimate remote–management tooling — its abuse here is the signal, not the concrete evidence of exploitation. Social–source artifacts from the @nahamike01 thread — uon_fanout.sh, /pay_or_leak, 382198 – Login, 108.174.202.99 — remain lower–confidence unless corroborated by  internal telemetry. 

Don’t stop at the vulnerability alert; correlate it with process, network, identity, configuration, and filesystem evidence. The workflow runs in sequence: from May 27, 2026 onward, identify external or untrusted POST requests to /PSEMHUB/hub and /PSIGW/HttpListeningConnector, then hunt the host for unexpected JSP files and recently modified XML metadata under PSEMHUB paths, unauthorized MeshCentral agents, outbound SMB on TCP/445, SSH–based movement, and extortion–marker files — before deciding whether exposure has become an incident. 

What Qualys Customers Should Do Now

Qualys customers should use QID 387611 (Oracle PeopleSoft Enterprise PeopleTools RCE — CVE–2026–35273) to identify PeopleSoft assets requiring immediate triage, then convert those findings into a prioritized validation queue covering production, disaster recovery, non–production, clones, training, vendor–hosted, and cloud–hosted environments. A QID finding should seed the investigation; on its own it proves neither exploitability nor compromise. 

For each matched asset, validate: 

• PeopleTools version, patch level, and support status 
• Whether EMHub/PSEMHUB and PSIGW are enabled and externally reachable 
• Whether a confirmed patch or mitigation is in place 
• What internal systems the PeopleSoft tier and its service accounts can reach 

Confirm external exposure across web–tier hostnames, DNS names, certificates, reverse–proxy/WAF and NAT/load–balancer paths, and cloud public–IP inventory. Include DR and standby nodes and managed estates. Require MSPs and MSSPs to provide QID status, version, mitigation, and configuration evidence — not generic assurance. Treat uncertain configuration as exposure until disproven. 

Remediation

Apply Oracle’s fix for CVE–2026–35273; this is the priority action. Confirm the exact patched build for PeopleTools 8.61 and 8.62 through the Patch Availability Document on My Oracle Support, which requires support entitlement. For unsupported, earlier releases, plan migration to a supported version rather than assuming a fix is available. 

If immediate patching is not possible, shrink the attack surface in the meantime: 

• Disable the Environment Management Hub (multi–server) or remove the PSEMHUB application (single–server) where feasible 
• Block external access to /PSEMHUB/*, /PSEMHUB/hub, and /PSIGW/HttpListeningConnector at the perimeter — not by WAF body inspection alone 
• Block outbound SMB (TCP/445) from PeopleSoft hosts to untrusted destinations 
• Validate that all remote–management tooling on PeopleSoft hosts is authorized 

Whether patching or mitigating, prove it on every node — including DR, standby, cloned, cloud–hosted, and managed environments. A fix is not complete until the node is actually patched or mitigated, restarted or redeployed where required, and verified — not assumed. If suspicious telemetry exists, preserve evidence and escalate from vulnerability response to incident response.