We demonstrate with Phoenix that all DDR5 devices from SK Hynix, currently the largest DRAM manufacturer, are still vulnerable to a new variant of Rowhammer attacks. Our reverse engineering of their in-DRAM Rowhammer mitigations reveals more sophisticated protection mechanisms, which resist all known Rowhammer patterns. To identify blind spots in the new mitigations, we conducted a series of carefully designed experiments, which revealed that the mitigation does not sample certain refresh intervals. This allowed us to craft two novel Rowhammer patterns that effectively bypass these deployed mitigations.
However, due to the patterns’ extensive length, covering thousands of refresh intervals, we had to come up with a new way of very precisely synchronizing with all these refresh operations. Phoenix’s self-correcting refresh synchronization automatically detects and realigns the pattern’s execution whenever it detects a missed refresh operation during the attack. We evaluate Phoenix on 15 DDR5 DIMMs from SK Hynix and show that it can trigger bit flips on all of them. We also demonstrate that the bit flips are exploitable by building the first Rowhammer privilege escalation exploit running in default settings on a PC in as little as 109 seconds. You can find the demo of this exploit below:
Reverse Engineering DDR5
We designed FPGA-based experiments to study the behavior of the Target Row Refresh (TRR) in-DRAM Rowhammer mitigations. Similar to previous work, we use retention errors as a side channel to determine rows refreshed by TRR. We first zoom out to determine the sampling period of the mitigation before zooming in to understand the sampling strategy.
Zooming Out. We conducted experiments in which we incrementally increased the length of the tested Rowhammer pattern. We performed double-sided hammering of a different aggressor pair in every tREFI interval such that each interval corresponds to another victim row. Afterwards, we determined which victim rows got refreshed by TRR. Using this method, we found that after 128 tREFI intervals, the sampling period repeats, which is 8x larger than the sampling period considered by existing Rowhammer patterns.
Zooming In. Studying the TRR’s sampling mechanism showed no consistent sampling behavior in the first 64 tREFI intervals. In the last 64 tREFI intervals, however, our experiment showed a repeating pattern in every four intervals. More precisely, sampling almost never happens in the first two intervals, which we call lightly sampled intervals. More fine-granular experiments within these lightly sampled intervals, involving up to 59 distinct victim rows, revealed which DRAM activations are always sampled.
Equipped with these insights, we explain how we derived effective Rowhammer patterns leveraging blind spots to evade the mitigations.
New Rowhammer Patterns
From our reverse engineering results, we derived a new Rowhammer pattern. In total, we reverse-engineered two devices, resulting in two new Rowhammer patterns, which together bypass the mitigations of all 15 DDR5 devices from SK Hynix of our test pool.
Our shorter pattern consists of 128 tREFI intervals. Due to the inconsistent sampling behavior, we do not hammer in the first part of the pattern. In the second part, we focus on the lightly sampled intervals (i.e., the first two intervals) but never on the last two intervals. The second part is repeated sixteen times, i.e., we hammer in every pattern repetition for 32 tREFI intervals in total.
We successfully tested our patterns on our FPGA infrastructure and found that 8 of 15 DDR5 devices from SK Hynix were vulnerable. We repeated the reverse engineering for another device from which we derived another pattern, covering 2608 tREFI intervals. We refer the interested reader to Appendix A of our paper for more details.
Hitting vulnerable offsets. Our pattern requires a precise alignment with the TRR-internal refresh state. We found that only 2 of 128 (1.56%) refresh offsets are vulnerable. However, the same offset occurs in every bank. Therefore, we increase the probability of proper refresh alignment by hammering shifted pattern instances in parallel on each of the four banks. This increases the probability of hitting a vulnerable offset by 16x, i.e., to 25%.
Self-Correcting Synchronization
A major challenge of porting the Phoenix patterns to a commodity system like a workstation or laptop is the pattern’s length. As the new patterns are up to 163x longer than current patterns, keeping synchronized with refresh commands becomes challenging. To this end, we evaluated the state-of-the-art refresh synchronization routine from Zenhammer and a multi-threaded variant of it. Our results show that they are both unsuitable to keep synchronized for long enough to induce any bit flips, even when reducing the number of activations per tREFI interval.
We overcame this challenge by designing a new self-correcting refresh synchronization method. Rather than perfectly detecting every refresh command, our method relies on the periodicity of the refresh command for realigning the hammer pattern’s execution whenever it detects that a refresh was missed. This enables us to keep in sync for thousands of refresh intervals.
Results
We test our Phoenix attack patterns on 15 DDR5 DIMMs from SK Hynix, manufactured between the end of 2021 and the end of 2024. We found that all 15 DIMMs are vulnerable to exactly one of the two patterns. Generally, the shorter pattern (128 tREFI intervals) is 2.62x more effective than the longer pattern (2608 tREFI intervals), leading to 4989 bit flips on average. We also analyzed the practical exploitability of these bit flips across three previously shown attacks targeting (i) page-table entries (PTEs) to craft an arbitrary memory read/write primitive (all DIMMs are vulnerable); (ii) RSA-2048 keys of a co-located VM to break SSH authentication (73% of vulnerable DIMMs); and (iii) the sudo binary to escalate local privileges to the root user (33% of vulnerable DIMMs). To demonstrate the real-world practicality, we reproduced the privilege escalation exploit from Rubicon for the first time on DDR5 DIMMs and demonstrated that the average time to exploitation is just 5 minutes and 19 seconds.
| Table: Evaluation of DDR5 UDIMMs. For each DIMM, we report its manufacturing date (MfD.); size (Sz.); DRAM geometry (number of ranks (RK), bank groups (BG), banks per bank group (BA), and row bits to the power of two(R)); and the Rowhammer pattern it is vulnerable to (§ 5). For each DIMM, we sweep its pattern over 256MB of memory and report the number of one-to-zero (1→0) and zero-to-one (0→1) bit flips. We also report the average time to find the first exploitable bit flip for three Rowhammer attacks: the page table entry (PTE) attack, the RSA key attack, and the sudo binary attack. | |||||||||||
| ID | MfD. | Sz. | Geom. | Patterns | Sweep [#BFs] | Attacks [mm:hh] | |||||
| [yy-mm] | [GiB] | (P128 / P2608) | 1→0 | 0→1 | PTE | RSA | sudo | ||||
| H0 | 21-12 | 8 | 1,4,4,16 | ✓ | ✗ | 3 329 | 5 460 | 00:10 | 04:57 | 80:45 | |
| H1 | 22-07 | 16 | 1,8,4,16 | ✓ | ✗ | 2 917 | 4 582 | 00:14 | 07:06 | 49:37 | |
| H2 | 22-08 | 16 | 1,8,4,16 | ✓ | ✗ | 2 629 | 4 082 | 00:15 | 06:38 | – | |
| H3 | 22-12 | 8 | 1,4,4,16 | ✓ | ✗ | 2 837 | 4 526 | 00:11 | 06:36 | – | |
| H4 | 22-12 | 32 | 2,8,4,16 | ✗ | ✓ | 207 | 318 | 02:55 | – | – | |
| H5 | 22-12 | 32 | 2,8,4,16 | ✓ | ✗ | 3 922 | 5 821 | 00:11 | 04:17 | – | |
| H6 | 23-01 | 32 | 2,8,4,16 | ✓ | ✗ | 6 592 | 9 672 | 00:07 | 02:29 | 20:19 | |
| H7 | 23-01 | 32 | 2,8,4,16 | ✗ | ✓ | 566 | 860 | 00:39 | – | – | |
| H8 | 23-01 | 32 | 2,8,4,16 | ✗ | ✓ | 156 | 240 | 04:06 | – | – | |
| H9 | 23-01 | 32 | 2,8,4,16 | ✗ | ✓ | 314 | 486 | 02:17 | 09:25 | – | |
| H10 | 23-02 | 32 | 2,8,4,16 | ✗ | ✓ | 304 | 461 | 07:27 | 23:57 | – | |
| H11 | 24-01 | 16 | 1,8,4,16 | ✗ | ✓ | 12 523 | 18 446 | 00:06 | 01:19 | 12:41 | |
| H12 | 24-01 | 16 | 1,8,4,16 | ✓ | ✗ | 10 833 | 15 917 | 00:05 | 01:27 | 21:17 | |
| H13 | 24-04 | 16 | 1,8,4,16 | ✓ | ✗ | 8 520 | 12 761 | 0:005 | 01:38 | – | |
| H14 | 24-12 | 16 | 1,8,4,16 | ✗ | ✓ | 24 | 19 | 20:15 | – | – | |
Further Information
Our paper will be presented at IEEE Symposium on Security and Privacy 2026. You can find the artifacts accompanying our publication on GitHub. Google has published a blog post about our joint work in the Google Security Blog.
FAQs
We provide answers to the most frequently asked questions about Phoenix.
Do the results imply that DDR5 devices from other vendors are protected against Rowhammer?|
No, due to the extensive effort of reverse engineering the in-DRAM Rowhammer mitigations, we limited ourselves to devices from the largest DRAM manufacturer, SK Hynix.
Which implications do these new results have for me?
We have proven that reliably triggering Rowhammer bit flips on DDR5 devices from SK Hynix is possible on a larger scale. We also proved that on-die ECC does not stop Rowhammer, and Rowhammer end-to-end attacks are still possible with DDR5. As DRAM devices in the wild cannot be updated, they will remain vulnerable for many years. We recommend increasing the refresh rate to 3x, which stopped Phoenix from triggering bit flips on our test systems.
How can I check if my SK Hynix DDR5 DRAM is vulnerable?
You can use our open-sourced proof-of-concept (POC) code on GitHub that triggers bit flips using the Phoenix attack. This code is tailored to an AMD Zen 4 system. If the POC triggers any bit flips, your DDR5 device is affected by one of our two found patterns.
Why is Rowhammer still not solved with DDR5?
Rowhammer is an DRAM industry-wide, known problem. The Rowhammer patterns used by Phoenix demonstrate that deployed in-DRAM mitigations protect against existing attacks but have not been designed in a principled way that would completely stop Rowhammer.
Does self-correcting refresh synchronization also work on DDR4?
Yes, we think that our new synchronization method should also work on systems with DDR4 DRAM. We have not measured if self-correcting synchronization also improves results on DDR4 systems, but it is likely.
Do DDR5 DIMMs equipped with on-die ECC (ODECC) stop Rowhammer?
No, we show that bit flips accumulate over time as ODECC only corrects bits after writing data or after a certain time (e.g., every 24 hours). Therefore, just hammering for longer—as we show in Section 5.2 of our paper—allows bypassing ODECC.
How can I protect myself against the Phoenix attack?
As a mitigation for existing DRAM modules, we verified that tripling the refresh rate (tREFI ≈ 1.3 us) stops Phoenix from triggering bit flips on our test systems. Running SPEC CPU2017, we have measured that this mitigation incurs an overhead of 8.4%. For future devices, more principled mitigations are required to stop Rowhammer completely.
Did you responsibly disclose your findings?
We started a responsible disclosure of Phoenix through the Swiss NCSC to SK Hynix, CPU vendors, and major cloud providers on June 6, 2025. The issue remained under embargo until September 15, 2025. We were informed on September 12 that there is a BIOS update for AMD client machines to address the issue, but we could not independently verify if this update adequately addresses Phoenix. Phoenix is tracked under CVE-2025-6202. More information, including the source code for all the experiments and the exploit, can be found at the following URL: https://github.com/comsec-group/phoenix.
Acknowledgments
We would like to thank the anonymous reviewers for their feedback and the Vulnerability Management team from the Swiss NCSC, who provided us with significant coordination support for disclosing this issue to the affected parties. This work was supported in part by a generous gift from Google.