Phoenix is a sophisticated evolution of the Rowhammer attack, newly demonstrated against DDR5 memory modules, which were previously considered resilient due to advanced hardware mitigations like Target Row Refresh (TRR). Researchers at ETH Zurich reverse-engineered TRR's behavior and discovered two critical timing windows during which the refresh protections are less effective. By performing a sequence of dummy memory accesses, the attack lulls TRR into a false sense of security, then executes a targeted hammering phase that flips bits in adjacent memory cells. This bit flipping can corrupt critical data structures, enabling three practical attack scenarios: arbitrary memory read/write via page table entry manipulation, theft of RSA-2048 private keys from memory, and privilege escalation by bypassing Linux sudo protections. The attack was tested successfully on 15 DDR5 modules from SK Hynix, paired with AMD Zen 2 and Zen 3 CPUs, though some modules resisted certain attack variants. The exploitation time ranges from seconds to minutes, making it feasible in real-world scenarios given sufficient system knowledge and access. The attack highlights that despite increased refresh rates and proprietary TRR implementations, DDR5 memory remains vulnerable to Rowhammer-style attacks. Proposed countermeasures include reducing refresh intervals (at the cost of power and heat), deploying ECC memory to detect and correct bit flips, implementing Fine Granularity Refresh at the memory controller level, and moving away from security through obscurity by adopting open, peer-reviewed mitigation techniques.

For European organizations, Phoenix poses a tangible threat to systems using DDR5 memory modules, particularly those with AMD Zen 2 or Zen 3 processors and SK Hynix memory. The ability to induce bit flips can compromise confidentiality by leaking sensitive data such as private encryption keys, integrity by corrupting critical memory structures, and availability by causing system crashes. Privilege escalation via sudo bypass can facilitate lateral movement and persistence within networks. Sectors relying on high-assurance computing, such as finance, government, and critical infrastructure, could face increased risk of data breaches or operational disruption. The attack's requirement for detailed system knowledge and local code execution limits its scope but does not eliminate risk, especially from insider threats or sophisticated attackers. The lack of known exploits in the wild currently reduces immediate risk but the demonstrated feasibility suggests attackers may develop exploits in the future. Organizations with large deployments of vulnerable hardware may face challenges in timely mitigation due to hardware replacement costs and complexity of patching firmware or BIOS-level protections.

European organizations should first inventory their hardware to identify systems with DDR5 memory modules, AMD Zen 2/3 CPUs, and SK Hynix memory, as these are confirmed vulnerable. Deploy ECC memory where possible to detect and correct bit flips, reducing attack success probability. Work with hardware vendors to obtain firmware or BIOS updates that improve TRR or implement Fine Granularity Refresh protections. Consider reducing memory refresh intervals if supported, balancing power and thermal impacts. Employ strict access controls and monitoring to prevent unauthorized local code execution, as the attack requires running malicious code on the target system. Harden Linux sudo configurations and audit privilege escalation vectors. Promote transparency by engaging with vendors about proprietary security mechanisms and encourage adoption of open, peer-reviewed mitigations. For critical systems, consider hardware isolation or virtualization-based security to limit attack surface. Finally, maintain up-to-date endpoint detection and response tools capable of identifying suspicious memory access patterns indicative of Rowhammer attacks.