Weekly Threat Bulletin – June 17th, 2026

GreatXML BitLocker 0-Day Bypass Exploited Through Defender Offline Scan

A newly identified zero-day vulnerability, dubbed "GreatXML," enables a complete bypass of BitLocker encryption on Windows systems by exploiting Microsoft Defender's Offline Scan feature. This flaw, discovered by security researcher NightmareEclipse, leverages an interaction between the Windows Recovery Environment (WinRE) and the `unattend.xml` configuration file. An attacker with physical access can copy a specially crafted `unattend.xml` file and a `Recovery` directory to the machine's recovery partition; upon rebooting into WinRE, the environment processes these files without proper integrity validation, granting unrestricted access to the BitLocker-protected volume without requiring a decryption key. This vulnerability is particularly critical if Defender Offline Scan has ever been initiated on the target machine, making it passively susceptible without requiring prior login. The root cause lies in WinRE's insufficient validation of external configuration files, a weakness that renders even BitLocker Version 2.0 with XTS-AES 128 encryption ineffective, especially when using TPM-only protection. To mitigate this threat, which affects Windows 11 and Windows Server 2025, defenders should immediately switch BitLocker from TPM-only to TPM+PIN mode, restrict physical access to endpoints, and monitor WinRE integrity for unauthorized files within the recovery partition.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Use Group Policy to enforce the "Require additional authentication at startup" setting for BitLocker, and configure it to require a startup PIN with TPM on all Windows devices.
• Deploy a PowerShell script using your endpoint management solution to add a TPM+PIN protector to all BitLocker-encrypted volumes on high-value systems, such as executive laptops and administrator workstations.
• Create and run a script across all endpoints to scan for the existence of `unattend.xml` files or unauthorized `Recovery` directories on the Windows Recovery Partition and generate alerts for any positive findings.
• Send an immediate security bulletin to all employees reminding them of the policy to secure company laptops and not leave them unattended in public or unsecured areas.

Compliance Best Practices

• Update the corporate device imaging and provisioning process to ensure BitLocker with a TPM+PIN protector is enabled by default on all new Windows endpoints.
• Incorporate the patching of the Windows Recovery Environment (WinRE) into the monthly security patch management lifecycle, ensuring that updates addressing WinRE vulnerabilities are tested and deployed consistently.
• Establish and enforce a strict physical security policy for all company facilities, including mandatory badge access for sensitive areas, a clean desk policy, and visitor escort procedures.
• Configure a custom detection rule in your Endpoint Detection and Response (EDR) solution to continuously monitor for and automatically block the creation of `unattend.xml` files on the recovery partitions of all managed endpoints.

ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit

UNC6240, also known as ShinyHunters, executed an active compromise and extortion campaign between May 27 and June 9, 2026, targeting Oracle PeopleSoft application infrastructure, with a significant focus on the higher education sector. This campaign exploited CVE-2026-35273, a critical (CVSS 9.8) zero-day remote code execution vulnerability in PeopleSoft's Environment Management component (PSEMHUB), prior to Oracle's public advisory. Attackers established command and control using customized MeshCentral agents, masquerading as Azure services, which communicated with `wss://azurenetfiles.net:443/agent.ashx` from staging IPs including `142.11.200.186-190`. The threat actors performed internal reconnaissance, executed lateral movement via SSH credential spraying using a script named ``[victim_abbreviation]_fanout.sh`,` and deployed a defacement file (`README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT`), ultimately exfiltrating data and publishing it on the ShinyHunters Data Leak Site. To defend against this activity, organizations must immediately disable the EMHub Service or remove the PSEMHUB application, block external access to `/PSEMHUB/*` and `/PSIGW/HttpListeningConnector`, and implement comprehensive log and filesystem monitoring for indicators of compromise, including specific C2 network indicators and hashes of malicious agents, while also applying all Oracle Critical Patch Updates.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Immediately disable the Oracle PeopleSoft Environment Management Hub (EMHub) Service or remove the PSEMHUB application entirely from your PeopleSoft servers.
• At the network perimeter firewall, create rules to block all external ingress traffic to the `/PSEMHUB/*` and `/PSIGW/HttpListeningConnector` URL paths on your Oracle PeopleSoft servers.
• Add the IP addresses 142.11.200.186, 142.11.200.187, 142.11.200.188, 142.11.200.189, and 142.11.200.190 to your network firewall blocklist.
• Block the domain `azurenetfiles.net` at your DNS firewall or web proxy.
• Review PIA WebLogic access logs for any HTTP POST requests to `/PSEMHUB/hub` or `/PSIGW/HttpListeningConnector` that originated from external IP addresses.
• Scan PeopleSoft web-tier filesystems for any unexpected `.jsp` files located under the `/webserv//applications/peoplesoft/PSEMHUB.war/` directory.
• Use your EDR or a manual script to scan all systems for files matching the SHA-256 hashes provided in the article's 'Staging Payloads & Attacker Files' table.
• On all PeopleSoft hosts, search the entire filesystem for the filenames `README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT` and `_fanout.sh`.
• Review firewall and NetFlow logs for any outbound SMB traffic (TCP port 445) originating from PeopleSoft servers to external internet destinations.

Compliance Best Practices

• Establish and enforce a patch management policy that requires all critical Oracle security alerts and updates to be applied to PeopleSoft systems within a defined timeframe.
• Implement network segmentation to isolate PeopleSoft application servers from database servers and from the general corporate network, restricting server-to-server communication to only explicitly approved protocols and hosts.
• Implement a default-deny egress firewall policy for servers in the PeopleSoft environment, allowing outbound connections only to known, required destinations and blocking protocols like SMB (TCP/445) and SSH (TCP/22) to the internet by default.
• Enforce a policy of strong, unique passwords for all service and administrative accounts on PeopleSoft and underlying infrastructure. Audit for and remove or disable any default or shared credentials.
• Implement public key-based authentication for all administrative SSH access between servers and disable password-based SSH authentication.
• Conduct a comprehensive architectural review of all internet-facing applications to ensure administrative or system-to-system components are not exposed to the public internet.
• Develop and deploy custom SIEM detection rules to alert on suspicious command-line activity on PeopleSoft servers, such as processes reading sensitive configuration files like `psappsrv.cfg` or `config.xml`.

Why Use App-Level Auth When Every Database Has Auth? (Splunk Enterprise CVE-2026-20253 Pre-Auth RCE)

Splunk Enterprise is affected by CVE-2026-20253, a pre-authentication Remote Code Execution (RCE) vulnerability with a CVSS score of 9.8, impacting versions 10 and above, particularly Splunk Enterprise on AWS where the vulnerable PostgreSQL Sidecar Service is enabled by default. The vulnerability stems from a lack of authentication in the PostgreSQL Sidecar Service endpoint, which listens on localhost:5435 but can be proxied through the main Splunk web application on port 8000 without credentials. Attackers can exploit the `/v1/postgres/recovery/backup` endpoint by manipulating the `backupFile` parameter to achieve arbitrary file creation and truncation. Further exploitation involves injecting connection string parameters like `hostaddr` into the `database` argument of the `pg_dump` command, forcing Splunk to connect to an attacker-controlled PostgreSQL database and dump its contents to an arbitrary file on the Splunk filesystem. The `/v1/postgres/recovery/restore` endpoint, which executes ``pg_restore`,` can then be abused by injecting the `passfile` parameter to point to Splunk's internal `.pgpass` file (`/opt/splunk/var/packages/data/postgres/.pgpass`), authenticating as ``postgres_admin`.` By restoring a malicious database dump containing SQL functions that use ``lo_export`,` an attacker can achieve arbitrary file write as the `splunk` user. This arbitrary file write can then be leveraged to overwrite frequently executed Python scripts, such as ``/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py`,` leading to full RCE. Mitigation requires upgrading Splunk Enterprise to versions 10.4.0, 10.2.4, 10.0.7, 9.4.12, or 9.3.13, or higher.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Use the provided 'watchTowr-vs-Splunk-RCE-CVE-2026-20253.py' script or a similar manual check to identify all Splunk Enterprise instances vulnerable to CVE-2026-20253. Prioritize scanning internet-facing and AWS-hosted instances.
• Upgrade all identified vulnerable Splunk Enterprise instances to a patched version (10.4.0, 10.2.4, 10.0.7, or higher) as specified in the Splunk advisory for CVE-2026-20253.
• If patching is not immediately possible, configure your Web Application Firewall (WAF) or reverse proxy to block all HTTP POST requests to URL paths containing '/splunkd/__raw/v1/postgres/recovery/backup' and '/splunkd/__raw/v1/postgres/recovery/restore'.
• In your web server, proxy, or SIEM logs, search for evidence of exploitation attempts by querying for HTTP POST requests to URI paths containing '/v1/postgres/recovery/backup' or '/v1/postgres/recovery/restore'.
• On Splunk servers, search for recently created or modified files by the 'splunk' user in common temporary directories like '/tmp/' or unexpected file paths, which could indicate a successful file write from the exploit.
• Analyze network flow logs or firewall logs for unexpected outbound connections from Splunk servers to external IP addresses on TCP port 5432 (PostgreSQL).

Compliance Best Practices

• Establish a process to review and disable non-essential services and components in enterprise software like Splunk, particularly after major version upgrades, to maintain a minimal attack surface.
• Implement a default-deny egress network policy for application servers, including Splunk, allowing outbound connections only to explicitly approved IP addresses and ports.
• Deploy and configure a File Integrity Monitoring (FIM) solution on Splunk servers to alert on any unauthorized changes to application binaries, configuration files, and scripts in the Splunk installation directory.
• Incorporate a 'zero trust' security principle into your application development and procurement policies, requiring that all internal API endpoints and services mandate strong authentication and authorization, even for localhost communications.

Critical Authentication Bypass in UpdraftPlus Plugin Enables Remote Code Execution

CVE-2026-10795 describes an unauthenticated authentication bypass vulnerability in the UpdraftPlus WordPress plugin, affecting versions up to and including 1.26.4, with a CVSS score of 8.1. The vulnerability resides in the UpdraftCentral remote communication layer, where a forged `format=1` RPC message can bypass signature verification. This bypass occurs because the `format=1` path does not require the same signature validation as newer message formats. When RSA decryption of the symmetric key fails, the `false` result is not rejected in vulnerable versions, leading to a predictable null key/null IV behavior in the symmetric decryption process. This allows an attacker to craft an encrypted RPC payload using a known zero key and zero IV, which can then be successfully decrypted and dispatched as a privileged UpdraftCentral command. The demonstrated attack chain involves an unauthenticated attacker sending a forged RPC request, bypassing authentication, and then leveraging legitimate plugin management commands like `plugin.upload_plugin` to install and activate a malicious plugin, achieving remote code execution (RCE-style impact) in the web server's context. This exploit requires an existing UpdraftCentral local key state associated with a privileged WordPress user. Detection involves monitoring unauthenticated POST requests to the WordPress front page containing `format=1` and `udrpc_message` fields, as well as unexpected plugin installations or activations. The issue is resolved in UpdraftPlus version 1.26.5, which adds a guard to reject invalid symmetric keys before decryption and command dispatch. Mitigation requires upgrading to version 1.26.5 or later, reviewing and removing stale UpdraftCentral keys, and monitoring for suspicious activity.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Update all instances of the UpdraftPlus WordPress plugin to version 1.26.5 or later immediately.
• Search web server access logs for unauthenticated POST requests to the WordPress site root that contain the fields `udrpc_message` and `format=1`.
• Inspect the `wp-content/plugins/` directory on all WordPress servers for any recently added or unexpected plugins.
• Implement a Web Application Firewall (WAF) rule to block or alert on POST requests that contain the string `udrpc_message` and `format=1` in the request body.
• Review all WordPress sites for configured UpdraftCentral keys and immediately remove any that are not actively required for business operations.

Compliance Best Practices

• Establish and enforce an automated patch management policy for all WordPress core, plugin, and theme updates to ensure critical vulnerabilities are remediated within a defined service-level agreement (SLA).
• Deploy a File Integrity Monitoring (FIM) solution on all WordPress servers to generate real-time alerts for any unauthorized file additions or modifications within the `wp-content/plugins/` directory.
• Create a formal policy to review and approve the use of any remote management features within plugins, such as UpdraftCentral, ensuring they are disabled by default and only enabled with a documented business justification and risk assessment.
• Configure all WordPress web servers to forward access and application logs to a centralized SIEM, and create specific alert rules for suspicious web request patterns, including unauthenticated POSTs with RPC-like parameters.
• Establish a quarterly review process to audit all WordPress plugins, themes, and user accounts, ensuring all components are necessary, up-to-date, and configured with the principle of least privilege.

How to Defend ARM64 Cloud Infrastructure from ITScape

ITScape (CVE-2026-46316) is a guest-to-host escape vulnerability affecting KVM/arm64, stemming from a race condition in the `vgic_its_invalidate_cache()` function that results in a double-put use-after-free. This flaw enables host kernel code execution from an untrusted guest, posing a significant threat to multi-tenant arm64 cloud environments, and can be chained with local privilege escalation if guest root is not initially held. The vulnerability impacts Linux kernels from commit `8201d1026caa` (April 25, 2024) through `13031fb6b835` (June 5, 2026), with the patch available at the latter commit. Detection can be achieved using two YARA rules: `ITScape_ExploitConstants_1` targets nine hardcoded 64-bit constants from the exploit's Proof-of-Concept (PoC) source, including kernel symbol addresses and a packed host command string, while `ITScape_KVM_PrivDrop_1` identifies a behavioral pattern involving a `stat(2)` group permission check on `/dev/kvm` followed by `setgroups(0, NULL)`, `setgid(1000)`, and `setuid(1000)` calls. The SHA256 hash of the PoC is `e0ab84da2d2783c8cae3624e8ce58b99ad79219753b249671ff7f743abdacc35`. Defenders should prioritize applying the mainline patch at commit `13031fb6b835` and its two companion fixes, and continue monitoring the `vgic-its` code path for expected additional variants.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Identify all ARM64 KVM hosts and apply the kernel patch for CVE-2026-46316 (mainline commit 13031fb6b835) or update to a patched kernel version provided by your Linux distribution vendor.
• Use your Endpoint Detection and Response (EDR) or other file scanning tools to search for the file with SHA256 hash e0ab84da2d2783c8cae3624e8ce58b99ad79219753b249671ff7f743abdacc35 on all systems, prioritizing ARM64 hosts and guests.
• Deploy the YARA rules `ITScape_ExploitConstants_1` and `ITScape_KVM_PrivDrop_1` provided in the article to your security tools capable of YARA scanning, such as EDR, network monitoring solutions, or manual file scanners.
• Use your vulnerability management platform or run scripts to scan and identify all ARM64 KVM hosts running a vulnerable Linux kernel version to prioritize patching efforts.

Compliance Best Practices

• Establish a formal process to monitor security mailing lists (e.g., oss-security) and code repositories for key infrastructure components like the Linux kernel's KVM subsystem, focusing on ARM64-related security issues.
• Review and streamline the patch management lifecycle for critical infrastructure kernel updates to minimize the time between patch release and deployment on production virtualization hosts.
• Enhance logging and monitoring on KVM hosts to detect anomalous activity, such as unexpected process execution, privilege escalation, or network connections that could indicate a successful guest escape.
• For multi-tenant KVM environments, research and implement stronger isolation technologies, such as more restrictive seccomp-bpf profiles or alternative sandboxing mechanisms, to limit the kernel attack surface available to guest VMs.