A Windows 11 administrator can turn writable configuration data on some consumer memory modules into access to physical memory that Virtualization-Based Security is meant to isolate. The software-only technique needs no physical access. In controlled tests, it let researchers patch the secure kernel, disable Microsoft Defender and third-party EDR, and revive drivers that Windows had blocked.
The USENIX Security 2026 paper calls the technique Download More RAM. The University of Birmingham publication record dates its presentation to August 12–14. Microsoft assigned CVE-2026-23670 and shipped a partial mitigation in its April 14 security update. The researchers did not report attacks in the wild. Their starting point is already powerful: local administrator access on a Windows 11 endpoint with a memory module that lacks Serial Presence Detect write protection.
A DIMM reports invented capacity
A DIMM records its capacity, timing, voltage, and geometry in a small Serial Presence Detect, or SPD, chip. Sam Collins, Tom Chothia, William Burgess, Marius Muench, and David Oswald found that several consumer modules left the SPD blocks containing core geometry writable.
Their attack changes the number of row-address bits so a module reports twice its physical capacity. The invented upper range points back to the real lower range. The alias bypasses protections attached only to the lower address.
That change alone makes Windows crash during boot. The researchers used the removememory boot parameter to keep the operating system in the lower half of the apparent address space. After restart, they mapped a small RAM disk over selected alias addresses. This gave them a limited write primitive against code-integrity components in the protected half.
The first write patches skci.dll, the secure-kernel code-integrity module, so its vulnerable-driver revocation checks no longer work. A previously blocked signed driver then supplies stable arbitrary reads and writes across installed physical memory. The paper summarizes the result directly: “our attack allows arbitrary memory read/write” across the operating system’s protection levels.
The alias crosses protected boundaries
VBS uses Hyper-V to put security services in a separate Virtual Trust Level. Hypervisor-Enforced Code Integrity, Credential Guard, and protected processes depend on page permissions and isolated address spaces to keep the ordinary Windows kernel away from their memory. Aliasing undercuts that assumption because two addresses reach the same physical cells.
The researchers demonstrated four end-to-end cases on Windows 11 25H2. They changed protected-process metadata to terminate Defender and Sophos EDR processes, patched a VBS-isolated process, and modified game anti-cheat state. These are research demonstrations. They are not evidence that CVE-2026-23670 has been exploited.
The hardware scope is meaningful but bounded. The team tested selected DDR4 and DDR5 UDIMMs. At least one tested line from Corsair, ADATA, and G.Skill left all relevant SPD blocks unprotected. Partial SPD protection was enough to stop this technique. HyperX, Kingston, and other tested G.Skill modules had partial protection. The sample was not exhaustive, so a vendor name alone cannot establish whether a deployed module is affected.
The attacker needs local administrator rights, a restart, a signed-driver path to writable SPD, and a stable aliased boot. This is a post-compromise boundary failure. The paper does not show a remote path to administrator access.
The researchers packaged the post-administrator sequence as a one-click script that continues across the restart without further interaction.
Figure details
A local administrator rewrites unprotected SPD geometry on a consumer DIMM and restarts the Windows 11 endpoint. The DIMM reports twice its real capacity, making upper addresses alias lower physical memory. The attacker stabilizes Windows with the removememory boot parameter, places a RAM disk over selected alias addresses, and patches secure-kernel code integrity. A re-enabled vulnerable driver then provides arbitrary physical-memory access across Defender, EDR, VBS-protected processes, and other security boundaries. Microsoft's April 14 update silently ignores removememory when Secure Boot is enabled, blocking the demonstrated stabilization step.
April blocks the demonstrated path
Microsoft confirmed the research and included mitigation in the April 14, 2026 Windows security update. On updated systems with Secure Boot enabled, Windows silently ignores removememory. That prevents the published chain from keeping aliased memory out of normal operating-system use, so the machine becomes unstable before the attacker reaches the reliable write primitive.
The researchers describe this as a partial mitigation. Systems without Secure Boot remain affected by the demonstrated chain. They also say the SPD rewrite, alias, RAM-disk write, and code-integrity patch remain intact. A different technique for stabilizing Windows could therefore restore the attack on Secure Boot systems.
Microsoft’s April 14 baselines are Windows 11 26H1 build 28000.1836, Windows 11 25H2 build 26200.8246, Windows 11 24H2 build 26100.8246 from that same update, and Windows 11 23H2 build 22631.6936. Later cumulative updates supersede these baselines and retain their security changes.
Corsair confirmed the attack. The paper says discussions with other affected memory manufacturers were ongoing. Epic Games, Riot Games, and Sophos also acknowledged the research.
Verify secure boot and memory
First, confirm each Windows 11 endpoint has the April 14 cumulative security update or a superseding update. On Windows 11 23H2, run:
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumberCompare OsBuildNumber with the installed release: 28000.1836 or later for 26H1, 26200.8246 or later for 25H2, 26100.8246 or later for 24H2, and 22631.6936 or later for 23H2. Later cumulative builds supersede those April baselines. Then run Confirm-SecureBootUEFI from an elevated PowerShell session. The expected result is True; False means the published Download More RAM chain retains its stabilization path, while an error requires separate confirmation that the system uses UEFI and supports Secure Boot.
Inventory DIMM manufacturer, product line, part number, DDR generation, and SPD write-protection state on privileged Windows workstations, gaming systems, anti-cheat environments, and endpoints where local administrators are intentionally constrained by VBS. Vendor inventory is a triage signal. The useful hardware test is whether the SPD blocks containing core geometry reject writes. Coordinate that test with the system or DIMM vendor because an unsafe write can prevent boot or corrupt the module configuration.
For incident response, look for an unexpected change in reported memory capacity, changes to boot configuration, a restart followed by a RAM-disk driver or service, access to SPD through SMBus or I2C-capable drivers, and attempts to load drivers on Microsoft’s vulnerable-driver blocklist. Preserve the exact boot configuration and driver-install records before remediation. The clean verification state is a current cumulative build, Secure Boot returning True, stable physical-memory inventory, and no unexplained SPD, boot, RAM-disk, or blocked-driver sequence during the exposure window.
The April update closes the researchers’ demonstrated stabilization route under Secure Boot. Hardware-backed isolation still depends on the configuration beneath it. Defenders should verify both layers before treating VBS as evidence that an administrator-level intrusion was contained.