A recent discovery dubbed Phoenix (CVE-2025-6202) shows that modern DDR5 memory modules—specifically those made by SK Hynix between 2021 and 2024—are more vulnerable than previously thought. Researchers from ETH Zürich and Google reverse-engineered the in-DRAM protections SK Hynix had built in and found gaps in the “Target Row Refresh” (TRR) mechanisms: certain refresh intervals were not sampled, allowing attackers to self-correct and synchronize memory hammering and trigger bit flips. In tests, Phoenix was able to bypass all known mitigations and gain root access on a standard desktop system in about 109 seconds under default settings. It also succeeded in stealing RSA-2048 keys from a co-located virtual machine and altering privilege boundaries via sudo. While the only temporary defense is increasing DRAM refresh rates (3× the normal rate, which carries performance penalties), the deeper conclusion is that future DRAM designs need stronger, more principled mitigations such as per-row activation counters to be secure.
Sources: ComSec.ethz.ch, Hacker News
Key Takeaways
– Existing Mitigations Are Not Enough: Standard protections like on-die ECC and advanced TRR schemes in SK Hynix DDR5 modules still leave blind spots that can be exploited by the Phoenix attack.
– Serious Real-World Impact: Attackers can escalate privileges, access sensitive keys (e.g. RSA-2048), or fully compromise systems in under two minutes using commodity hardware with default settings.
– Mitigations Trade Off Performance, and New Designs Needed: Increasing refresh rates helps mitigate Phoenix but with performance and stability costs. Long-term safety requires redesigning DRAM defenses (e.g. per-row activation counting) rather than relying on band-aid fixes.
In-Depth
The Phoenix discovery marks a troubling new chapter in hardware security vulnerabilities. For years, RowHammer has been a known threat: the ability to repeatedly access (or “hammer”) a row of DRAM cells to induce bit flips in adjacent rows has been demonstrated since 2014, mostly in DDR3 and DDR4 devices. Over time, vendors added mitigations—error-correcting code (ECC), Target Row Refresh (TRR), and other refresh rate adjustments—to make these attacks harder. Until recently, DDR5 was thought to be more resilient thanks to improved internal refresh management and denser protection schemes. But Phoenix reveals that the guardrails are not impermeable.
Researchers from ETH Zürich and Google systematically reverse-engineered the TRR mechanisms inside SK Hynix DDR5 modules and saw that while many intervals were protected, some refresh intervals were not sampled—those blind spots are where Phoenix finds its entry. The attack operates by keeping track of thousands of refresh operations. When a missed refresh interval (i.e. a gap in the protection coverage) is detected, the attack self-corrects and hammers at precisely the moments needed. Across their test pool—15 SK Hynix DDR5 DIMMs made between 2021 and 2024—they triggered bit flips in all of them. What’s worse, they didn’t just produce bit flips: they converted them into practical exploits, including root escalation in minutes under default settings, stealing RSA keys, and altering system binaries like sudo.
The implications are broad. For users and system builders, the short-term remedy is painful: increase refresh rates to triple standard rates. This makes Phoenix much harder to execute, but at a cost—higher power usage, possible instability, and performance drops. For chip manufacturers and the hardware security community, the Phoenix attack underlines that incremental mitigations are no substitute for robust design: mechanisms such as per-row activation counters that give strong guarantees of protection will likely become essential. As DRAM geometries shrink and modules pack more densely, electrical interference between memory cells will only become harder to manage; attacks like Phoenix may be a harbinger of more to come rather than an isolated anomaly. Maintaining trust in system memory security now depends on both software (firmware/BIOS updates) and hardware evolution.