A newly disclosed Windows attack technique, dubbed “Download More RAM,” can undermine Virtualization-Based Security (VBS), bypass Hypervisor-Protected Code Integrity (HVCI), and disable endpoint protections including Microsoft Defender and third-party EDR products.
The attack was presented at USENIX Security 2026 and is tracked by Microsoft as CVE-2026-23670. Unlike a conventional Windows kernel exploit, Download More RAM targets a hardware configuration weakness in some consumer DDR4 and DDR5 memory modules.
The attack abuses writable Serial Presence Detect (SPD) data, which is configuration information held in an EEPROM on a DIMM. SPD tells motherboard firmware a module’s capacity, layout, speed, and operational parameters.
Download More RAM Attack Bypasses Windows VBS
If the SPD EEPROM lacks effective write protection, an attacker who already has local administrator privileges can modify the DIMM’s reported memory geometry.
This causes the system to believe that a memory module contains more RAM than is physically installed. In demonstrations, researchers caused a machine to report approximately twice the actual capacity of an affected module.
The manipulated RAM configuration produces a condition known as memory aliasing. Windows treats multiple physical memory addresses as separate locations, even though they point to the same underlying DRAM cells.
This breaks a fundamental assumption made by the operating system, processor, and hypervisor. Instead of simply triggering instability, USENIX found a way to stabilize Windows and use the overlapping address space to access memory regions that should remain isolated.
The name “Download More RAM” refers to the system appearing to gain additional memory through software alone. No extra physical RAM is installed, and the demonstrated attack does not require attackers to remove, reflash, or replace the DIMM.
Windows VBS uses Hyper-V and Virtual Trust Levels to isolate sensitive components from the ordinary Windows kernel. These protected components can include the Secure Kernel, Credential Guard, isolated user-mode processes, and security-sensitive code that executes at Virtual Trust Level 1.
By creating memory aliases, the researchers accessed physical memory areas that even a privileged Windows administrator should not be able to read or modify.
The proof-of-concept chain reportedly relied on legitimate signed tooling to inspect aliased memory and a RAM-disk mechanism to apply constrained changes to specific memory regions.
The team then patched skci.dll, the Secure Kernel Code Integrity library, disabling checks that enforce Microsoft’s vulnerable-driver blocklist.
With that protection weakened, an attacker could load legitimately signed but vulnerable drivers that expose physical-memory read and write primitives. Those primitives can negate the isolation boundaries that VBS and HVCI are intended to enforce.
USENIX demonstrated scenarios involving disabling Microsoft Defender protections, impacts on Sophos Intercept X configurations, modification of VBS-protected enclave code, and interference with kernel-level anti-cheat products.
USENIX found writable SPD configurations in selected consumer memory products from Corsair, G.Skill, and ADATA, but the survey was not comprehensive.
Protection can differ by vendor, product line, model, and firmware configuration. DIMMs with properly write-protected SPD blocks are not susceptible to the demonstrated software-only attack path.
Microsoft released a mitigation for CVE-2026-23670 in its April 2026 security updates. The fix prevents the Secure Boot-compatible removememory boot configuration mechanism that researchers used to stabilize Windows during their demonstrated attack.
Updated systems with Secure Boot enabled are protected against the presently documented attack chain. Organizations should immediately deploy the latest Windows security updates, verify that Secure Boot is enabled, and monitor systems for unexpected changes to boot configuration.
Security teams should also review motherboard BIOS or UEFI settings for SPD write-protection options and seek vendor guidance for installed RAM modules.
Monitoring should focus on vulnerable driver loading attempts, unusual kernel memory access behavior, and administrative changes to boot or memory configuration.
While Microsoft’s update disrupts the published technique, writable SPD remains the underlying hardware issue. SPD write protection should therefore be treated as a defense-in-depth control, rather than relying exclusively on operating-system patching.
Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world
