Listen to this Post

Introduction: When RAM Becomes the Attack Surface
For years, Windows security has increasingly moved beyond traditional antivirus protection. Technologies such as Virtualization-Based Security (VBS), Hypervisor-Protected Code Integrity (HVCI), Secure Boot, Credential Guard, and endpoint detection and response (EDR) products are designed to create security boundaries that even a highly privileged attacker should struggle to cross.
But researchers have now demonstrated an attack that challenges one of the assumptions underneath those defenses: the operating system can trust the memory hardware to accurately describe itself.
The technique, called “Download More RAM,” does not require an attacker to physically remove a memory module, install modified hardware, or exploit a conventional Windows kernel vulnerability. Instead, it abuses writable configuration information stored on certain DDR4 and DDR5 memory modules.
Researchers from the University of Birmingham and Durham University presented the technique at USENIX Security ’26, describing it as a software-only memory-aliasing attack capable of undermining VBS and allowing privileged attackers to reach protected areas of system memory. USENIX describes the technique as capable of providing arbitrary physical memory read/write access on affected systems and impacting the secure kernel, HVCI, Windows Defender, third-party security software, and game anti-cheat systems.
That makes the story far more serious than its playful name suggests.
The Strange Idea Behind “Downloading” RAM
The name sounds like an old internet joke: download more RAM, double your memory, and somehow make the computer faster.
The researchers turned that joke into a security concept.
The attack abuses Serial Presence Detect (SPD) information stored on memory modules. SPD data tells a computer’s firmware important characteristics about a DIMM, including its capacity and organization.
Normally, the system reads this information and uses it when configuring physical memory.
The problem appears when the SPD configuration can be modified when it should effectively be treated as trustworthy and immutable.
If an attacker with local administrator privileges can alter the memory geometry reported through SPD, the operating system can be persuaded to believe that a DIMM contains more addressable memory than it physically possesses.
The computer has not actually gained additional RAM.
Instead, the system has been tricked into creating an address map that does not correspond cleanly to the physical DRAM underneath it.
Memory Aliasing Is Where the Real Danger Begins
This is the critical part of the attack.
When the reported memory layout no longer matches the physical memory configuration, multiple physical addresses can effectively point toward the same underlying DRAM locations.
This phenomenon is known as memory aliasing.
In ordinary circumstances, operating-system security mechanisms assume that physical memory addresses have predictable relationships with the underlying hardware.
The researchers demonstrated that manipulating those assumptions can create a path into memory regions that software should not normally be able to access.
USENIX describes the result as a software-only attack that can compromise operating-system defenses at multiple levels, including the secure kernel and HVCI.
Why VBS Exists in the First Place
To understand why this matters, it helps to understand what VBS is actually protecting.
Virtualization-Based Security uses the Windows hypervisor to establish isolated execution environments known as Virtual Trust Levels.
The objective is simple but powerful: even if an attacker compromises the normal Windows kernel, particularly sensitive security components should remain separated from it.
This architecture supports security features including the Windows secure kernel, Credential Guard, and protected or isolated processes.
HVCI adds another layer by enforcing code-integrity policies using virtualization-backed protections.
The basic philosophy is that the operating system should not be able to casually reach everything running beneath the security boundary.
“Download More RAM” attacks the assumptions beneath that architecture rather than simply attacking an ordinary Windows process.
From False Memory Capacity to Security Boundary Failure
The
There are several stages.
First, the attacker needs the necessary local administrative privileges.
Next, the vulnerable memory configuration is manipulated so that Windows creates the problematic memory mapping.
The operating system then needs to remain stable enough for the attacker to take advantage of the resulting alias.
From there, the researchers demonstrated methods for accessing memory that should normally be protected.
This eventually created a primitive capable of undermining the isolation VBS was designed to provide.
The Secure Kernel Becomes Part of the Battlefield
One of the most alarming aspects of the research is its demonstrated impact against the Windows secure kernel.
The researchers used their memory-access capabilities to interfere with components responsible for enforcing security policies.
According to the USENIX presentation, this included patching the Secure Kernel Code Integrity library, skci.dll, in their proof-of-concept environment.
That is significant because security software running at the ordinary Windows level is not necessarily designed to defend against an attacker who can directly manipulate the protected memory underneath it.
Once those assumptions collapse, many defensive layers become considerably less meaningful.
HVCI Is Not the Only Protection at Risk
The consequences extend beyond HVCI.
The researchers demonstrated attacks affecting Windows Defender and third-party endpoint security software, as well as VBS-protected code and popular game anti-cheat technologies.
The research specifically examined environments involving products and systems such as Sophos Intercept X, Riot Vanguard, BattlEye, and Easy Anti-Cheat.
The important lesson is not that every installation of these products is automatically vulnerable.
The deeper lesson is that security software cannot completely compensate for a compromised hardware-to-memory trust boundary.
The Vulnerable-Driver Problem
Windows has spent years tightening restrictions around vulnerable drivers because signed kernel drivers can become extremely powerful attack primitives.
A legitimately signed but vulnerable driver may contain weaknesses that allow privileged attackers to perform operations they otherwise could not perform.
Microsoft’s vulnerable-driver blocklist exists partly to prevent known dangerous drivers from being loaded.
The researchers showed how their memory-aliasing technique could be used to interfere with the mechanisms enforcing these restrictions.
Once a vulnerable signed driver becomes available, it can potentially provide powerful access to physical memory.
At that point, the attacker is no longer fighting Windows security from the outside.
They are operating with capabilities dangerously close to the hardware itself.
The Attack Does Not Mean Every Windows PC Is Vulnerable
This distinction is extremely important.
“Download More RAM” is not a universal attack against every Windows computer.
The researchers surveyed selected consumer memory modules and identified systems where SPD protections were insufficient.
Their research identified affected product lines involving vendors including Corsair, G.Skill, and ADATA, but they explicitly warned that the survey was not exhaustive.
A particular brand therefore should not automatically be considered vulnerable.
The exact DIMM model, SPD implementation, firmware behavior, motherboard configuration, and platform protections all matter.
Why the Hardware Supply Chain Matters
This research highlights an uncomfortable reality for modern cybersecurity.
Security teams often focus heavily on Windows versions, applications, drivers, cloud services, browsers, and identity systems.
Memory modules are rarely treated as part of the active security boundary.
Yet modern computers depend on firmware and hardware configuration data long before Windows has fully started.
If that configuration data can be manipulated in a way that changes how the operating system understands physical memory, the resulting security consequences can reach far beyond the memory module itself.
This is essentially a hardware trust problem disguised as a software attack.
The Difference Between “BadRAM” and “Download More RAM”
The concept also resembles earlier research into malicious or manipulated memory configurations, including BadRAM-style attacks.
But there is a major distinction.
Earlier techniques could require physical access to memory modules or physical modification of hardware.
“Download More RAM” is notable because the researchers demonstrated a software-only path on affected systems.
That changes the threat model dramatically.
An attacker does not necessarily need to open the computer case.
They need a sufficiently privileged foothold on the machine and vulnerable memory hardware.
USENIX explicitly characterizes the technique as requiring no physical access to the affected system.
Microsoft Assigned CVE-2026-23670
Microsoft assigned CVE-2026-23670 to the underlying Windows security issue associated with the research.
The vulnerability is officially described as a Windows VBS security-feature bypass involving an untrusted pointer dereference, with local exploitation requiring high privileges and high attack complexity. NVD lists Microsoft’s CVSS 3.1 base score as 5.7.
This classification is worth understanding.
A medium CVSS score does not mean the research is unimportant.
CVSS describes the
The April 2026 Windows Mitigation
Microsoft addressed CVE-2026-23670 through Windows security updates released in April 2026.
The patch mitigates the demonstrated attack path, but the researchers have cautioned that the broader hardware-level memory-aliasing issue remains relevant and that alternative ways of stabilizing the affected system could potentially preserve portions of the attack concept.
That distinction matters.
A patch can close the specific path researchers demonstrated without making every possible interaction between writable SPD configuration and memory mapping impossible.
Why Security Teams Should Not Stop at Windows Update
Applying
But organizations should think beyond the operating-system patch.
Security teams should also investigate whether systems permit SPD configuration writes, whether motherboard firmware provides relevant protections, whether Secure Boot is enabled, and whether hardware inventories can identify potentially affected memory modules.
This is especially important for organizations that operate large fleets of Windows workstations where hardware configurations vary significantly between procurement batches.
Deep Anlysis: Defensive Checks Administrators Can Run
The following commands are useful for defensive verification. They do not perform the attack. They help administrators establish the Windows build, inspect VBS configuration, verify Secure Boot, and inventory memory modules.
Check the Windows Build
Get-ComputerInfo | Select-Object ` WindowsProductName, WindowsVersion, OsBuildNumber
This provides a quick way to identify the Windows release and build currently installed.
Check VBS Configuration
Get-CimInstance -Namespace "root\Microsoft\Windows\DeviceGuard" ` -ClassName Win32_DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning
A security team can use this to determine whether VBS is configured and which relevant security services are active.
Check Secure Boot
Confirm-SecureBootUEFI
A result of True indicates that Secure Boot is enabled and recognized by Windows.
If the command reports False, the machine should be investigated according to the organization’s security baseline.
Inventory Installed Memory
Get-CimInstance Win32_PhysicalMemory | Select-Object Manufacturer, PartNumber, SerialNumber, Capacity, Speed, ConfiguredClockSpeed
This is particularly useful for identifying the exact DIMM models installed across a fleet.
The PartNumber field can be especially valuable when comparing deployed hardware against vendor advisories.
Check Memory Capacity
Get-CimInstance Win32_ComputerSystem |
Select-Object TotalPhysicalMemory
This provides the physical memory capacity reported by Windows and can be correlated with the installed DIMM inventory.
Check Recent Windows Updates
Get-HotFix | Sort-Object InstalledOn -Descending |
Select-Object -First 20
Administrators can use this as a quick review of recently installed Windows updates.
For authoritative patch validation, however, organizations should compare their installed builds against Microsoft’s security-update guidance rather than relying exclusively on individual KB listings.
Do Not Try to Reproduce the Attack on Production Systems
The research is technically fascinating, but defenders should resist the temptation to test exploit code against production endpoints.
The attack interacts with memory mapping, firmware configuration, privileged Windows components, and kernel-level security mechanisms.
A failed experiment could cause system instability, data corruption, crashes, or an unbootable system.
Organizations that need to validate exposure should use isolated research hardware, vendor-supported diagnostic procedures, and controlled testing environments.
Hardware Vendors Have a Role to Play
Microsoft cannot solve every aspect of this problem through Windows updates.
Memory vendors and motherboard manufacturers also have an important responsibility.
SPD configuration should be appropriately protected against unauthorized modification.
Firmware should avoid exposing unnecessary write capabilities to privileged software.
Manufacturers should provide clearer documentation about SPD write protection and firmware behavior.
The security community has historically treated RAM as something computers consume rather than something attackers can manipulate as a configuration trust anchor.
That mindset may need to change.
Enterprise Procurement May Need to Change Too
Large organizations could eventually begin treating memory modules as security-relevant components.
Hardware procurement processes could record exact DIMM part numbers instead of simply recording “32 GB DDR5” or “64 GB DDR4.”
That additional detail can make vulnerability management significantly more effective.
It also makes hardware replacement and incident response easier when a specific memory model becomes associated with a newly discovered security weakness.
Why Local Administrator Access Still Matters
There is an important limitation that should not be overlooked.
This is not a remote unauthenticated attack that allows someone on the internet to instantly compromise an ordinary Windows machine.
The demonstrated attack requires a privileged local foothold.
That substantially raises the barrier for attackers.
However, local administrator access should not be dismissed as harmless.
Modern intrusion chains frequently involve credential theft, privilege escalation, malicious installers, remote-management abuse, phishing, or compromised software that eventually grants an attacker elevated privileges.
Once attackers reach administrator-level access, “Download More RAM” could potentially become an additional escalation path on suitable hardware.
The Real Security Lesson: Defense in Depth Has a Hardware Boundary
Security professionals often talk about defense in depth.
The idea is that if one layer fails, another layer should continue protecting the system.
But “Download More RAM” illustrates a deeper problem.
If an attacker reaches a layer underneath several security controls, multiple defenses can fail simultaneously.
Instead of bypassing Defender, HVCI, EDR, and anti-cheat individually, an attacker can attack the assumptions that allow those protections to trust the memory environment.
That is why hardware-backed security is so important.
What Undercode Say:
The Name Is Funny, But the Research Is Not
“Download More RAM” sounds like an old computer meme, yet the underlying research exposes a genuinely serious security assumption.
The technique demonstrates that physical memory configuration can become a security boundary.
That is precisely the kind of boundary defenders tend to overlook.
The Attack Is More Interesting Than Its CVSS Score
CVE-2026-23670 carries a Microsoft/NVD CVSS 3.1 score of 5.7.
At first glance, that may sound moderate.
But CVSS should never be interpreted without understanding the attack chain.
The demonstrated technique can undermine defenses that organizations normally consider extremely difficult to bypass.
Privileged Access Is Still a Major Requirement
Attackers cannot simply send a malicious packet to a Windows machine and “download more RAM.”
They need local administrative privileges.
That significantly limits immediate exploitation.
But privileged access is often the point attackers work toward after compromising a machine.
Hardware Is Becoming Part of the Software Security Model
Modern Windows security relies heavily on hardware virtualization and trusted execution assumptions.
That means hardware configuration cannot remain completely outside the software security conversation.
The boundary between hardware security and operating-system security is becoming increasingly blurry.
SPD Should Be Treated More Seriously
SPD configuration is normally associated with compatibility and memory initialization.
This research demonstrates that it can have security consequences.
If SPD writes can influence the memory map presented to an operating system, write protection becomes more than a reliability feature.
It becomes a security control.
VBS Is Powerful, But Not Magical
VBS dramatically strengthens Windows security.
It should not be interpreted as an invincible wall.
Every security technology has assumptions.
The important question is not whether VBS is useful.
It clearly is.
The question is whether the layers underneath VBS can also be trusted.
The Vulnerable-Driver Ecosystem Remains Dangerous
Windows has made substantial progress in blocking vulnerable drivers.
But attackers continue to search for ways around those protections.
The research demonstrates why the vulnerable-driver problem remains relevant even when Microsoft’s blocklists are functioning as designed.
EDR Cannot Defend Against Everything
EDR products are extremely valuable for detecting suspicious behavior.
But an attacker who can manipulate memory beneath the security software creates a very different problem.
The lesson is not that EDR is useless.
The lesson is that EDR is one layer in a much larger security architecture.
Anti-Cheat Systems Face Similar Challenges
The impact on Vanguard, BattlEye, and Easy Anti-Cheat is especially interesting.
Anti-cheat systems frequently rely on deep operating-system visibility.
If protected memory can be read or modified, their assumptions can collapse too.
This could become an important research direction for gaming security.
Hardware Inventory Needs More Precision
Organizations should know exactly what hardware is deployed.
“Dell laptop with 32 GB RAM” is not sufficient for sophisticated hardware vulnerability management.
The exact DIMM model and part number can matter.
Firmware Deserves More Attention
BIOS and UEFI security is becoming increasingly important.
Organizations often patch Windows aggressively while leaving firmware versions and configuration controls less closely monitored.
That approach is becoming increasingly risky.
Secure Boot Still Matters
Secure Boot does not eliminate this attack class.
However, maintaining Secure Boot and other platform security controls remains an important defensive measure.
Security teams should treat it as one part of layered protection rather than a complete solution.
The Patch Is Still Essential
The existence of limitations in
Unpatched Windows systems remain exposed to the CVE itself.
The correct response is to patch first and then evaluate the broader hardware exposure.
Hardware Vendors Need Better Security Documentation
Security teams should not have to reverse-engineer whether a memory module’s SPD configuration is protected.
Manufacturers should clearly document write-protection mechanisms and security implications.
Supply-Chain Security Is Expanding
This research is another example of why supply-chain security cannot stop at software packages.
Hardware components have firmware, configuration storage, controllers, and trust relationships.
Every layer can become part of an attack surface.
The Attack Changes the Threat Model
Traditional endpoint attacks usually begin with software.
This one begins with a configuration mechanism associated with physical memory.
That makes it conceptually different.
Attackers Will Look for Trust Assumptions
The most interesting attacks often do not break cryptography directly.
They exploit assumptions.
“Download More RAM” demonstrates exactly that pattern.
Windows trusts the memory map.
The attack manipulates the assumptions behind that trust.
Security Architecture Needs Hardware Awareness
As operating systems become more dependent on virtualization and hardware-backed security, software security teams will increasingly need hardware expertise.
The traditional separation between endpoint security and hardware engineering is becoming less practical.
Cloud Providers Should Pay Attention Too
The research focuses on consumer Windows systems.
That does not mean the underlying concept is irrelevant to cloud environments.
Cloud providers use sophisticated memory virtualization and hardware abstraction layers.
Any vulnerability involving memory accounting, mapping, or hardware trust deserves serious scrutiny in virtualized infrastructure.
Enterprises Should Build Hardware Exposure Into Incident Response
If a compromised administrator account is detected, defenders should know whether the endpoint’s hardware could enable unusual post-compromise techniques.
Hardware inventories can become useful forensic data.
Memory Modules May Become Security-Critical Assets
This could eventually change how organizations classify RAM.
A memory module is no longer necessarily just a performance component.
Its configuration storage can influence how the operating system understands physical resources.
Security Research Is Moving Down the Stack
Recent security research increasingly targets firmware, processors, memory, virtualization, and hardware interfaces.
“Download More RAM” fits directly into this trend.
Attackers are not always interested in breaking the application.
Sometimes the better target is the layer underneath it.
The Most Dangerous Vulnerabilities Are Not Always Remote
Remote code execution receives enormous attention because of its obvious danger.
But local vulnerabilities can also be devastating when they provide the final capability needed after an attacker has already obtained privileged access.
The Attack Shows Why Privilege Escalation Still Matters
Even when an attack requires administrator access, defenders should not underestimate it.
Privilege escalation is frequently a central stage of real-world attacks.
A powerful post-compromise technique can turn a limited breach into a complete compromise.
The Research Also Shows the Value of Academic Security Work
This is an excellent example of academic research uncovering a problem that conventional vulnerability scanning might never find.
There was no ordinary application crash to discover.
The researchers questioned a fundamental assumption about memory configuration.
That is precisely why independent security research remains so valuable.
Security Teams Should Think in Chains
The individual steps of the attack are important.
The chain is more important.
Memory configuration manipulation leads to aliasing.
Aliasing leads to protected-memory access.
Protected-memory access can undermine code-integrity enforcement.
That can enable vulnerable drivers.
Those drivers can provide even greater memory access.
The result is a cascade.
The Research Should Not Create Panic
Most Windows users do not need to panic.
The attack has substantial prerequisites.
Affected hardware is not universal.
Microsoft has also issued a mitigation for the assigned CVE.
The appropriate response is disciplined patching and hardware awareness, not fear.
But Organizations Should Not Ignore It
For enterprises with high-value Windows endpoints, privileged workstations, security-sensitive systems, or unmanaged hardware procurement, this research deserves attention.
The cost of checking exposure is relatively small compared with the potential consequences of discovering the issue after an intrusion.
“Hardware Trust” Needs to Become a Security Term
Perhaps the biggest lesson is conceptual.
Security teams have become comfortable discussing identity trust, certificate trust, application trust, and software supply-chain trust.
Hardware trust deserves the same attention.
The Future of Endpoint Security Will Be More Integrated
Tomorrow’s endpoint security architecture will likely involve firmware, CPU features, memory protections, hypervisors, operating systems, drivers, and security agents working together.
Weaknesses at any one layer can affect the rest.
The Attack Is a Warning, Not the End
“Download More RAM” should not be viewed as proof that VBS has failed as a technology.
Instead, it demonstrates why security systems must continuously revisit their assumptions.
Attackers will always search for the layer nobody thought needed defending.
The Biggest Lesson for Defenders
The strongest security boundary is only as strong as the assumptions underneath it.
If Windows trusts memory configuration that can be manipulated, sophisticated isolation mechanisms can potentially inherit that weakness.
That is the real significance of “Download More RAM.”
✅ The “Download More RAM” Research Is Real
USENIX officially lists the research as “Download More RAM: Dismantling Windows Operating System Defences with Mischievous Memory.”
The authors demonstrated a software-only memory-aliasing attack capable of undermining Windows VBS, HVCI, and other defenses on affected systems.
✅ CVE-2026-23670 Is Real
Microsoft assigned CVE-2026-23670 to the Windows VBS security-feature-bypass issue.
NVD records
✅ The Attack Is Not a Universal Windows Exploit
The technique depends on specific hardware conditions involving memory configuration and is not automatically applicable to every Windows computer.
The researchers specifically state that their hardware survey was not exhaustive, meaning exact exposure depends on the DIMM and platform involved.
⚠️ “Patch Completely Solves the Hardware Problem” Would Be Misleading
Microsoft’s mitigation addresses the Windows attack path associated with CVE-2026-23670.
However, the researchers have indicated that alternative approaches to the memory-aliasing problem could remain relevant, so organizations should consider both software patching and hardware/firmware protections.
Prediction
(+1) Hardware Security Will Become a Bigger Part of Windows Defense
The most likely long-term consequence of “Download More RAM” is not mass exploitation of consumer PCs.
Instead, the research is likely to accelerate attention toward hardware-assisted security, firmware integrity, SPD write protection, and memory configuration security.
As Windows continues to depend on VBS, hypervisors, Secure Boot, TPMs, and hardware-backed isolation, researchers will increasingly look beneath the operating system itself.
(+1) Enterprise Hardware Inventory Will Become More Security-Focused
Organizations are likely to become more interested in exact DIMM models, firmware versions, motherboard capabilities, and platform security configurations.
That could eventually turn detailed hardware inventories into a normal component of vulnerability management.
(+1) Memory Vendors Will Face More Security Scrutiny
Memory manufacturers may increasingly be expected to treat SPD protection as a security feature rather than simply a reliability mechanism.
Future enterprise procurement requirements could explicitly include SPD write protection and firmware-level security controls.
(-1) Hardware Trust Failures Could Produce More Difficult Endpoint Attacks
The negative possibility is that researchers uncover additional weaknesses in the interfaces between Windows, firmware, memory, and virtualization.
Such vulnerabilities could be particularly difficult for conventional EDR products to detect because the attacker may operate beneath the visibility available to ordinary security software.
Final Thoughts: The Computer May Have More Than One Kernel-Level Battlefield
“Download More RAM” is memorable because of its name, but its real importance is much more serious.
The research demonstrates how a seemingly mundane component of computer memory configuration can influence the security guarantees of an operating system designed around virtualization and isolation.
The most important takeaway is not that Windows VBS is useless, nor that every DDR4 or DDR5 system is compromised.
It is that security boundaries depend on assumptions.
Windows can build increasingly sophisticated defenses around the kernel. Hyper-V can isolate sensitive workloads. HVCI can enforce stronger code integrity. Defender and EDR products can monitor suspicious behavior.
But if an attacker finds a way to manipulate the physical memory environment beneath those protections, several layers can potentially be challenged at once.
For defenders, the practical response is straightforward: keep Windows fully patched, verify Secure Boot and VBS configurations, inventory memory hardware, review BIOS/UEFI controls, monitor vendor guidance, and treat unusual privileged activity as a potential precursor to deeper compromise.
The joke about “downloading more RAM” has always been about something impossible.
This research turns that joke into a warning: sometimes the most dangerous attack is not adding something to a computer, but convincing the computer that something exists when it does not.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.reddit.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube




