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.
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.
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.
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.
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.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
