Mandiant and Google Threat Intelligence Group published a joint analysis on June 11 of an active compromise and extortion campaign attributed to UNC6240, the group tracked publicly as ShinyHunters. The campaign exploited CVE-2026-35273, a critical unauthenticated remote code execution vulnerability in the Environment Management component of Oracle PeopleSoft Enterprise PeopleTools, between May 27 and June 9, 2026. Oracle published its emergency advisory on June 10, the day after the campaign concluded and stolen data appeared on ShinyHunters’ data leak site.
CVE-2026-35273 sits in the Updates Environment Management component, specifically the Environment Management Hub endpoint (PSEMHUB). No authentication is required and no user interaction is needed: a network-accessible PSEMHUB endpoint is sufficient for exploitation over HTTP. Affected versions are PeopleTools 8.61 and 8.62. Oracle notes that earlier unsupported versions are likely also vulnerable.
Mandiant notified over 100 global organisations whose IP addresses correlated with potentially vulnerable exposed endpoints. Of those organisations, 68 percent were universities and academic institutions, most in the United States. ShinyHunters told The Register that the University of Nottingham was among the first publicly confirmed victims, with 40GB of student and billing records stolen and published after the university declined to pay the extortion demand. ShinyHunters stated that victim outreach was still ongoing at time of reporting.
The attackers’ staging infrastructure was exposed: open directories on servers at 142.11.200.186 through 190 contained tooling, payloads, and command histories that allowed Mandiant to reconstruct the attack chain in detail. Exfiltrated data was compressed using zstd and transferred via outbound SSH to 176.120.22.24, the IP hosting the ShinyHunters data leak site mirror.
- Block all external internet access to PeopleSoft Environment Management Hub (PSEMHUB) endpoints immediately. This removes the unauthenticated attack surface regardless of patch status.
- Apply Oracle’s emergency advisory and patch for CVE-2026-35273. Monitor My Oracle Support for availability for your specific PeopleTools version.
- Audit PeopleSoft access logs for activity between May 27 and June 9 for unusual requests to PSEMHUB endpoints, unexpected outbound SSH connections, and data transfers compressed with zstd.
- If your PSEMHUB endpoint was internet-accessible during the campaign window, treat the instance as potentially compromised and engage your incident response process.
Nightmare Eclipse, also known as Chaotic Eclipse, published the GreatXML exploit on June 10, one day after releasing RoguePlanet. The researcher described it as an accidental discovery that took four hours to find. The exploit targets the interaction between Windows Defender’s Offline Scan feature and Windows Recovery Environment boot configurations.
When a Defender Offline Scan has been initiated on a system, the presence of specific XML files on the recovery partition, namely unattend.xml and Recovery/WindowsRE/ReAgent.xml, causes WinRE to process them in a way that spawns a privileged shell with unrestricted access to BitLocker-protected volumes. An attacker with physical access places these files on the recovery partition, then reboots into WinRE by holding Shift while clicking Restart in the Windows power menu. The researcher notes that systems on which an offline scan has never been run may also be exploitable by first initiating the scan state, though this has not been fully investigated.
Microsoft has not assigned a CVE to GreatXML and has not published a patch or advisory as of today. The researcher published the proof-of-concept code on GitHub. The Cyderes Howler Cell team independently confirmed the technique. Unlike RoguePlanet, which is a local privilege escalation, GreatXML requires physical access to place the files and trigger the reboot.
- Monitor MSRC for a CVE assignment and emergency patch for GreatXML. Apply immediately when available, as with RoguePlanet.
- Assess whether managed device configurations limit access to the recovery partition. Group Policy settings that restrict WinRE access or require BitLocker PIN entry before recovery mode may reduce exposure.
- Prioritise physical security for laptops and devices containing sensitive data, particularly those in shared workspaces or frequently transported, as physical access is required to trigger GreatXML.
ServiceNow updated its security advisory KB3067321 on June 12 to state that the suspicious API activity observed on June 2 and 3 has been attributed to security researcher activity rather than malicious exploitation. The company states the endpoint that was accessible without authentication has been secured and that the advisory has been updated to reflect this revised attribution.
The original advisory, published on June 9, described the activity as a security incident and confirmed that external requests had been made to customer instance tables via the REST API endpoint. The updated advisory changes the characterisation of who made those requests. ServiceNow has not detailed how it determined the activity was researcher rather than attacker traffic, nor whether the researchers involved were authorised by the affected customer organisations.
- Review the updated ServiceNow advisory KB3067321. If your organisation initiated a formal breach notification process based on the original reporting, assess whether the revised attribution changes that determination.
- Document both the original and updated advisories. Regulated organisations should apply their own disclosure framework to the revised facts rather than relying solely on ServiceNow’s characterisation.