The research, presented this week at USENIX Security 2026 by researchers from the University of Birmingham and Durham University, is nevertheless a serious finding. It shows that VBS, HVCI, Credential Guard, Process Protection Light, and Microsoft’s vulnerable-driver blocklist can all be undermined when a machine combines the wrong RAM-module configuration with a pre-existing privilege compromise. Microsoft assigned the issue CVE-2026-23670 and shipped an initial mitigation in the April 14, 2026 Windows security updates.
For Windows administrators, the immediate work is straightforward: ensure affected Windows machines have received the April 2026 cumulative update or later, confirm Secure Boot is actually enabled, and treat unrestricted access to RAM configuration tooling as a security control problem rather than an overclocking curiosity.
The attack changes what “admin” can mean on Windows
VBS exists precisely because Windows administrators are not meant to have unlimited control over everything. It uses Hyper-V to isolate a secure kernel from the ordinary Windows kernel, allowing features such as HVCI and Credential Guard to enforce boundaries that an administrator-level process should not be able to overwrite directly.
The researchers’ attack, called Download More RAM, targets that separation indirectly. A DIMM exposes its specifications through Serial Presence Detect, or SPD: small configuration data stored on the module that tells firmware and the memory controller such things as capacity, timing, voltage, and physical organization. The attack alters a capacity-related field so that the system believes a DIMM has twice the memory it physically contains.
That false configuration does not create more RAM. It creates two addresses that resolve to the same underlying physical memory: an alias. If software can access a higher address that maps back to protected lower memory, processor and operating-system access controls tied to the intended address mapping no longer provide the protection Windows expects.
The USENIX paper says this can give an attacker arbitrary physical-memory read and write capability after the full chain is completed. From there, the team demonstrated modifications to the secure kernel’s code-integrity enforcement, the re-enabling of drivers Microsoft had blocked due to their use in malware campaigns, and attacks against VBS-protected processes, anti-malware tools, EDR software, and game anti-cheat systems.
This is why the finding deserves more attention than a routine “admin can disable security” observation. On a correctly configured VBS system, administrator rights alone are supposed to fall short of disabling several of those defenses. CVE-2026-23670 describes a route around that design through hardware configuration data Windows and the platform firmware accepted as trustworthy.
No physical access does not mean no prior compromise
The research removes a restriction from earlier BadRAM-style work, which generally assumed the attacker could physically remove a DIMM, alter its configuration, and reinstall it. In this case, the researchers showed that vulnerable modules can be reprogrammed through the system’s SMBus or I2C path from Windows software.
But the access requirement still sharply defines the practical risk. The paper assumes a Windows 11 machine where the attacker already has local administrator privileges and where the DIMM’s SPD configuration is not write-protected. The researchers specifically describe the scenario as applicable to rogue administrators, remote attackers who have already elevated privileges, and malware that has already done the same.
That distinction changes the incident-response priority. An organization does not need to assume that an internet-facing Windows 11 PC with an affected Corsair, G.Skill, or ADATA module can be compromised merely because the RAM is installed. An attacker first needs a way to run privileged code locally. Standard prevention against privilege escalation, credential theft, remote-management abuse, and administrator account misuse remains the first barrier.
The second factor is hardware-specific. The research team tested selected unbuffered DIMMs, rather than every product from every vendor. Their table identifies fully unprotected examples in certain Corsair Vengeance, G.Skill Aegis, and ADATA XPG DDR4 lines, as well as one tested Corsair Vengeance DDR5 module and one G.Skill Trident Z Neo DDR5 module. It also found partially protected modules from G.Skill, HyperX, Crucial, and Kingston; partial protection was sufficient to block this particular SPD rewrite.
So the vendor names in the headlines should not be read as a blanket verdict on every DIMM they sell. The paper explicitly says the authors did not exhaustively test all product lines and observed different protection states within G.Skill’s range. The reported market-share figures also estimate the presence of the manufacturers in performance and gaming memory, not the share of all installed modules that are exploitable.
Microsoft’s April fix blocks one step, not the underlying condition
Microsoft’s April mitigation deserves careful wording. The USENIX researchers say they observed that April’s Windows updates cause the removememory boot parameter to be ignored on Secure Boot-enabled systems. Their attack used that parameter to prevent Windows from using the upper, aliased half of memory during startup; without it, the altered memory mapping made the test machine unstable enough to frustrate the demonstrated chain.
NVD’s record for CVE-2026-23670 lists Windows 10, Windows 11, and supported Windows Server releases as affected before their respective April 2026 fixed builds. For Windows 11, the listed thresholds include build 22631.6936 for version 23H2, build 26100.8246 for version 24H2, and build 26200.8246 for version 25H2. Organizations that have applied later cumulative updates should retain the mitigation, but should verify patch compliance rather than assume an August update succeeded.
Secure Boot is central to the current protection. The research found that systems without Secure Boot remain susceptible to the published attack method. It also found that Windows can now run VBS protections without Secure Boot, a change that expands VBS availability but does not turn off the need for Secure Boot in this case.
There is a material limitation: the researchers characterize Microsoft’s response as a partial mitigation. The altered boot-parameter behavior breaks their known path for stabilizing Windows after memory aliasing, but it does not make a writable SPD configuration safe by itself. The paper says a different way to stabilize the operating system could revive the broader technique even where Secure Boot is enabled.
That is not a reason to defer patching. It is a reason not to describe April’s update as a permanent hardware-level repair. Microsoft has constrained the published exploit chain; it has not changed the fact that the affected DIMMs can permit software writes to information the platform uses to configure physical memory.
The hardware response is uneven
The research team says it notified affected RAM makers. Corsair confirmed the finding and worked with the researchers, according to the paper; discussions with other vendors were ongoing at publication. Neowin reports that Corsair added an iCUE option to enable write protection and that HWiNFO added similar functionality for non-Corsair memory, though the research paper itself is more cautious: it notes that vendor tools may be able to set SPD write protection, but some DIMMs may block an override.
That caveat is important before administrators start deploying scripts across a fleet. SPD writes are low-level operations. A tool that changes module protection state should be sourced from the module vendor or a well-established hardware-management utility, tested on representative hardware, and governed like firmware configuration—not run casually from an endpoint management platform.
The authors also point to motherboard firmware controls as an interim defense. Some boards offer an option to deny SPD writes through BIOS or UEFI settings. Fleet managers with enthusiast-class desktops, engineering workstations, gaming systems, or lab PCs should check their board documentation and configuration-management baselines for an SPD-write control. It is more meaningful than attempting to identify exposure solely through the RAM brand shown in an inventory report.
ECC memory is not presented as a solution. The researchers did not test ECC DIMMs in their evaluation and note that ECC does not inherently stop prior BadRAM attacks. Enterprises should therefore avoid treating ECC-equipped workstations or servers as automatically insulated from this issue without vendor confirmation of SPD write protection and a review of their platform settings.
What Windows administrators should do now
The practical response should focus on the conditions that make CVE-2026-23670 useful to an attacker:
- Apply the April 2026 Windows security update or a later cumulative update across Windows 10, Windows 11, and Windows Server systems, then confirm the relevant installed build rather than relying on update policy status alone.
- Verify that Secure Boot is enabled on capable endpoints. A machine with VBS enabled but Secure Boot disabled does not receive the protection that blocks the researchers’ current attack sequence.
- Reduce the number of users and tools with local administrator rights, especially on workstations where RAM tuning, RGB utilities, benchmark tools, hardware monitors, or overclocking software are routinely used.
- Identify systems using tested or similarly positioned consumer DIMMs, then consult the memory vendor and motherboard vendor for SPD write-protection options rather than assuming every module from a named vendor is vulnerable.
- Treat unexplained changes to boot configuration, sudden RAM-capacity discrepancies, anti-malware tampering, and attempts to load blocked drivers as incident indicators worthy of investigation.
The broader lesson is uncomfortable but clear. Windows 11’s most valuable protections can separate ordinary kernel control from the secure kernel, but they still depend on the machine describing its hardware honestly. In the systems covered by this research, an already-privileged attacker can falsify that description through writable DIMM configuration data. April’s Windows update and Secure Boot block the published chain today; hardening SPD writes is what closes the door closest to the hardware.