Researchers from ETH Zürich’s Computer Security Group have presented Phoenix, a new variant of Rowhammer that bypasses in-DRAM mitigations in DDR5 memory from SK Hynix — the largest DRAM manufacturer — achieving exploitably bit flips in all 15 analyzed DIMMs. The team demonstrates privilege escalation on a PC with default settings in just 109 seconds (average of 5 minutes and 19 seconds), and releases a functional exploit along with public artifacts for experimentation. The vulnerability has been assigned as CVE-2025-6202.
Context: Rowhammer in the DDR5 era
Rowhammer is a physical fault in DRAM where repeated accesses (hammering) to “aggressor” rows induce bit flips in an adjacent “victim” row. Recent memory generations incorporate in-DRAM mitigations such as Target Row Refresh (TRR) and on-die ECC (ODECC) to contain the phenomenon. However, Phoenix demonstrates that DDR5 has not “solved” Rowhammer: the analyzed mitigations have blind spots and ODECC doesn’t prevent the accumulation of flips over time.
Findings: Blind spots in TRR and self-correcting synchronization
Investigators reverse-engineered SK Hynix’s TRR using FPGA experiments and a side-channel based on retention errors to observe which rows the internal logic refreshes in response to hammering patterns:
- Sampling period: TRR repeats a sampling pattern every 128 refresh intervals (tREFI), which is 8× longer than previous Rowhammer patterns considered.
- Zoom-in: in the first 64 tREFI, sampling is inconsistent; in the last 64, a pattern emerges in groups of 4 intervals where the first two are almost never sampled (“lightly sampled“). These gaps are the blind spots.
Then, they created two new patterns that avoid the sampled windows and attack the lightly sampled ones:
- Short pattern (P128): 128 tREFI cycles, targeting only the second half, focusing on the two “lightly sampled” intervals and never the last two; repeated 16×.
- Long pattern (P2608): 2,608 tREFI for a second device type.
Results:
- All 15 SK Hynix DDR5 DIMMs (manufactured between 12/2021 and 12/2024) were vulnerable to one of the two patterns.
- P128 was 2.62× more effective than P2608 (average of 4,989 flips), but both bypassed mitigations.
Self-correcting synchronization
The patterns are up to 163× longer than traditional ones, making it difficult to synchronize with periodic refreshes (tREFI) in commodity systems. Phoenix introduces a self-correcting synchronization that detects desynchronization and resynchronizes execution based on refresh periodicity, remaining stable for thousands of intervals (outperforming previous syncs like Zenhammer, even in multi-threaded variants).
Parallel alignment and banks
Only 2 out of 128 refresh offsets are vulnerable (1.56%). Phoenix launches offset-shifted instances of the pattern in parallel across 4 banks, multiplying the chance of hitting a vulnerable offset by 16× (≈ 25%).
Demonstrated Exploitability: PTE, RSA, and sudo
The researchers evaluated three end-to-end attacks using the obtained flips:
- PTE attack: modifying page-table entries for arbitrary read/write in memory.
- All vulnerable DIMMs.
- RSA-2048 key exfiltration from a co-located VM to break SSH authentication.
- 73% of vulnerable DIMMs.
- Sudo attack: corrupting the sudo binary to escalate to root locally.
- 33% of vulnerable DIMMs.
In addition to a minimum attack time of 109 seconds, they report average exploit times around 5–10 minutes for PTE, and demonstrate the first Rowhammer privilege escalation on DDR5 reproducible on a default-configured PC.
ODECC is not enough & why TRR fails
- ODECC: fixes bits on write or after certain periods (e.g., every 24 hours). Phoenix shows flips accumulate if hammered long enough, bypassing ODECC (§5.2 of the paper).
- TRR: defends against known patterns, but Phoenix exploits a non-“principled” design (non-uniform sampling and long periodicity) to hit where TRR doesn’t look.
Conclusion: current mitigations reduce trivial attacks but do not close the issue; DDR5 remains exposed to Rowhammer with proper patterns and synchronization.
Scope and limitations
- The study focused on SK Hynix (“the largest manufacturer”) due to reverse-engineering costs; does not imply other providers are protected.
- The PoC for Phoenix (open-source) is adapted for AMD Zen 4; if it causes bit flips on your machine, your DIMM is vulnerable to one of the patterns.
- Phoenix is responsibly disclosed (via NCSC Switzerland) since June 6, 2025 to SK Hynix, CPU vendors, and major cloud providers; embargoed until September 15, 2025.
- An updated BIOS for AMD customers (September 12) was not independently verified by the authors.
Practical mitigations today (and their costs)
- Tripling refresh rate (tREFI ≈ 1.3 μs, ~3×): stopped Phoenix in testing systems.
- Measured overhead: 8.4% (SPEC CPU2017).
- Operational recommendations:
- In sensitive workloads (multi-tenant cloud, VDI, colocated VMs, high-security environments), consider increased refresh as a temporary mitigation.
- Monitor and segregate environments with cross-tenant content; minimize placement of attacker/victim with memory affinity.
- Keep firmware/BIOS up to date and watch for manufacturer alerts.
- Harden critical binaries (e.g., sudo) with additional integrity/verification and reduce attack surface.
- In the medium/long term: DRAM industry needs “principled” mitigations addressing periodicity and sampling in a verifiable manner, not just pattern lists.
What security and cloud teams should do
- Inventory: dump DIMMs DDR5 details (manufacturer, batch, on-die ECC, geometry).
- Risk assessment: is there multi-tenancy, arbitrary code access (e.g., unprivileged users), third-party workloads, critical integrity boundaries (PTE, keys, SUID binaries)?
- Controlled testing: use the PoC (Zen 4) in dedicated labs to validate actual exposure.
- Refresh policies: evaluate 3× tREFI in high-risk systems, measuring impact and setting exceptions.
- Detection and response: monitor for atypical memory corruptions, unexplained PTE or protected binary failures.
FAQs
Does this mean DDR5 from other manufacturers is safe?
No. The study only covered SK Hynix due to reverse engineering costs. Other vendors could be vulnerable to similar patterns.
Wasn’t Rowhammer “solved” in DDR5 with TRR and on-die ECC?
Phoenix shows not: TRR has explorable sampling gaps, and ODECC can be bypassed by accumulating flips with prolonged hammering.
What is the impact of increasing the refresh rate 3×?
In testing, it blocked Phoenix at a cost of about 8.4% performance (SPEC CPU2017). It’s a useful temporary mitigation in critical environments.
How do I know if my SK Hynix DDR5 modules are vulnerable?
Authors provide a PoC (targeting AMD Zen 4) that attempts to induce bit flips with Phoenix. If flips appear, that DIMM is vulnerable to P128 or P2608.
Does the self-correcting synchronization also work in DDR4?
The authors believe yes. They haven’t quantified the improvement in DDR4, but it’s likely to help.
References and availability
- Phoenix will be presented at the IEEE Symposium on Security and Privacy 2026.
- Code and research artifacts: GitHub (comsec-group/phoenix).
- CVE-2025-6202.
- Joint publication with Google Security Blog.
Conclusion
Phoenix raises the bar: it demonstrates that DDR5 remains susceptible to Rowhammer despite state-of-the-art in-DRAM mitigations. The combination of long patterns, self-correcting synchronization, and real exploitability (PTE/RSA/sudo) forces a reassessment of security assumptions in PCs, servers, and especially in multi-tenant clouds. Without definitive hardware solutions, operational mitigation (like the 3× refresh) and defense-in-depth remain the best response today.
via: comsec.ethz.ch