Scientists from the Computer Security Group (COMSEC) at the ETH Zürich college, in conjunction with Google, have published a proof-of-concept attack on DDR5 RAM called Phoenix, with the CVE number 2025-6202. The new attack causes bit-flips in memory, leading to a set of vulnerabilities that includes high-level privilege escalation. Phoenix adeptly bypasses DDR5's preventive measures for Rowhammer-style attacks, and neither ECC nor ODECC (on-die ECC) are of help.
It's worth noting that COMSEC only tested the attacks on an AMD Zen 4 platform, against 15 SK hynix DDR5 DIMMs from 2021-2024. The team states it chose the largest DRAM vendor, as the analysis is time-intensive even with the help of dedicated FPGA test boards. Having said that, the research is part of a Google-led effort for better RAM security in cooperation with JEDEC, the consortium that defines memory standards. It's also not the first time that COMSEC has worked on RAM security, having previously cooperated with VUSec to create the TRRespass attack.
Phoenix is a mix-up and evolution of existing Rowhammer-style attacks that repeatedly "hammer" a set of RAM locations with reads, in a specific pattern, in a bid to force at least one bit to flip via electromagnetic interference. This allows for extracting data or modifying code to an attacker's preference. The scenario is concerning enough in desktops and workstations, but particularly worrying in large-scale servers hosting thousands of clients. You can download the proof-of-concept software at COMSEC's Phoenix GitHub repository if you want to test your systems.
Phoenix's creators tested specific scenarios and had a 100% success rate in replicating attacks that manipulate Page Table Entries (PTE), granting access to forbidden locations in memory; a 73% chance of extracting the SSH login keys from a virtual machine in the same server; and a 33% probability of straight up getting root access thanks to manipulating the in-memory binary for the sudo utility. The team replicated the privilege escalation scenario in the Rubicon suite in only 5 minutes and 19 seconds flat. COMSEC's researchers revealed their findings past June 6 to SK hynix, CPU vendors, and the major cloud platforms, and will publish their findings at the IEEE Security & Privacy 2026 conference.
There's no bulletproof mitigation for this issue yet — at least for the tested SK hynix DIMMs — but the researchers state that increasing the row refresh rate (tREFI) in the machine's UEFI by 3 times down to around 1.3 μs makes the attacks unlikely to succeed. However, that comes at a steep cost, as a benchmark with the SPEC CPU2017 suite revealed a nasty 8.4% performance hit. COMSEC says there's an impending BIOS update for AMD client systems to address this problem, but couldn't verify its effectiveness as of the date of its publication.
Google points out in a related blog post that DDR5's TRR (Target Row Refresh) and ECC/ODECC can't quite fix the problem as they're not deterministic. For example, TRR's mechanism of triggering a refresh of a memory row doesn't keep an exact count of the number of accesses to it, making it easy to exploit by increasing the attack surface. Meanwhile, even the mighty ODECC only corrects bit-flips when data is written, or after a certain time (usually hours), meaning that just keeping an attack going for a long while is enough.
Those circumstances led to the creation of the PRAC (Per-Row Activation Counting) JEDEC standard, first announced in April 2024 for a future DD5 revision. PRAC keeps an accurate count of sequential accesses to a memory row and alerts the host system if a limit is exceeded, so that mitigation measures (likely a refresh) are implemented. Predictably, the upcoming LPDDR6 standard is integrating PRAC from the get-go. Here's to hoping the new feature will finally put a stake through Rowhammer's heart.
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Follow Tom's Hardware on Google News to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button.