- Phoenix (CVE-2025-6202) elude TRR y on-die ECC en DDR5 de SK Hynix, logrando root en minutos.
- Dos patrones (128 y 2608 tREFI) y sincronización auto-correctora explotan un punto ciego del muestreo TRR.
- 15 DIMMs probados: miles de flips, ataques a PTEs, robo de RSA-2048 y escalada vía sudo.
- Mitigación temporal: 3× refresco (≈8,4% de coste); artefactos públicos y coordinación con fabricantes.
La comunidad de seguridad y hardware vuelve a mirar a la memoria principal: un nuevo ataque de tipo RowHammer, bautizado como Phoenix (CVE-2025-6202), demuestra que determinados módulos DDR5 de SK Hynix siguen siendo vulnerables pese a contar con protecciones avanzadas. La investigación conjunta de ETH Zürich y Google revela, con pruebas reproducibles, que es posible escalar privilegios hasta root en equipos de sobremesa con ajustes por defecto en cuestión de minutos.
Más allá del titular, lo importante es que los investigadores han descrito con precisión por qué fallan las defensas integradas en DRAM (TRR) y cómo han logrado esquivarlas. Han documentado patrones de martilleo nuevos, una sincronización de refrescos auto-correctora y condiciones reales de explotación que afectan a entornos locales y multi‑tenant. Todo ello se acompaña de artefactos públicos y coordinación responsable con fabricantes y proveedores cloud.
Qué es RowHammer y por qué vuelve con fuerza
RowHammer es una debilidad de hardware en DRAM donde el acceso repetido a una fila puede provocar flips de bit en filas vecinas, generando corrupción de datos. Desde su demostración inicial en 2014 se ha visto que, a medida que se incrementa la densidad de las celdas para ampliar capacidad, el número de activaciones necesarias para inducir un bit flip se reduce, aumentando el riesgo.
Los impactos prácticos son bien conocidos: corrupción de estructuras críticas del sistema, elevación de privilegios o denegaciones de servicio. Investigaciones previas han mostrado que la susceptibilidad depende de múltiples variables, incluyendo temperatura, voltaje, variaciones de fabricación, patrones de datos almacenados, patrones de acceso a memoria y políticas del controlador.
Para contener el problema se han planteado mitigaciones como el Error Correction Code (ECC) y Target Row Refresh (TRR). Sin embargo, trabajos posteriores demostraron que esas defensas pueden eludirse con ataques más sofisticados: TRRespass, SMASH, Half‑Double o Blacksmith, entre otros. Incluso se han visto efectos en ámbitos aparentemente muy distintos, como el fingerprinting de dispositivos mediante variantes derivadas.
En paralelo, el organismo JEDEC introdujo recientemente un mecanismo de integridad llamado Per‑Row Activation Counting (PRAC) para detectar patrones propios de RowHammer y frenar el tráfico agresivo. Pero, según Google, los sistemas con DDR5 evaluados no han incorporado PRAC, lo que deja la puerta abierta a nuevas técnicas de explotación en producción.
Phoenix (CVE-2025-6202): quién lo ha descubierto y qué logra
Un equipo conjunto de ETH Zürich (COMSEC) y Google ha identificado un punto ciego en las defensas TRR integradas en DDR5 de SK Hynix. Phoenix obtiene la primera escalada de privilegios end‑to‑end en un PC de consumo con DDR5 estándar, alcanzando root con la configuración por defecto en tan solo 109 segundos en el caso más favorable, y con tiempos medios de explotación prácticos de 5 minutos y 19 segundos en ciertas demos.
La investigación se probó en un sistema con CPU AMD Zen 4 y módulos DDR5 de SK Hynix, con la intención de replicar posteriormente en otras memorias y procesadores. Los resultados afectan a 15 módulos fabricados entre 2021 y 2024: todos presentaron bit flips bajo alguno de los dos nuevos patrones desarrollados por el equipo. El ataque ha sido catalogado como CVE-2025-6202 y recibe una severidad alta en CVSS v4 (7.1), con valores y vectores documentados en fuentes como Mitre y NVD.
Un dato relevante: el on‑die ECC no evita RowHammer en DDR5. Los autores evidencian que los flips pueden acumularse con el tiempo, ya que el ECC en chip corrige al escribir o con correcciones periódicas (p. ej., cada 24 horas). Martillear durante más tiempo, con la cadencia adecuada, permite bypassear esa capa de protección.
Las posibilidades de explotación van desde alterar page tables para obtener lectura/escritura arbitraria, hasta extraer claves RSA‑2048 de máquinas virtuales colocalizadas (rompiendo autenticación SSH) o manipular binarios como sudo para elevar privilegios locales. Estamos, por tanto, ante un escenario con impacto tanto en estaciones de trabajo como en infraestructuras compartidas.
Cómo han logrado el bypass: TRR, periodos de muestreo y patrones nuevos
El corazón del hallazgo es la ingeniería inversa de las mitigaciones TRR en la DRAM. A través de experimentos basados en FPGA y usando errores de retención como canal lateral, los investigadores observaron que el sistema de muestreo de TRR repite su periodo cada 128 intervalos tREFI, un rango 8 veces más amplio que el contemplado por patrones clásicos de RowHammer.
Al “acercar el zoom”, el estudio muestra que, en los últimos 64 intervalos de ese ciclo, existe una subestructura repetitiva de cuatro sub‑intervalos donde los dos primeros se muestrean ligeramente o casi nada. Esa asimetría deja una ventana de oportunidad: si el martilleo se alinea con estas zonas “lightly sampled”, las defensas no detectan a tiempo la actividad agresiva.
Con esa pista, el equipo derivó dos patrones de larga duración. El primero cubre justo 128 tREFI; evita martillear al principio y concentra la actividad en las franjas de bajo muestreo, repitiendo esa segunda parte 16 veces para acumular 32 intervalos efectivos de martilleo por repetición. El segundo abarca un patrón mucho más largo de 2608 tREFI, pensado para otros dispositivos con diferencias internas.
La sincronización es crítica: solo 2 de 128 desplazamientos de refresco (offsets) son vulnerables, lo que da una probabilidad de acierto inicial del 1,56%. Para aumentar opciones, lanzan la misma secuencia desplazada en paralelo sobre cada uno de los cuatro bancos, multiplicando por 16 la probabilidad de enganchar el offset correcto hasta aproximadamente el 25%.
Sincronización auto-correctora: el gran salto frente a intentos previos
Un reto clave era conservar la alineación con los refrescos durante miles de intervalos, ya que los patrones de Phoenix son entre 1 y 2 órdenes de magnitud más extensos que los habituales. Los autores comprobaron que la rutina de sincronización de Zenhammer, incluso en variantes multi‑hilo, no mantiene la estabilidad el tiempo suficiente para provocar flips de manera fiable.
La solución pasa por una técnica de sincronización auto‑correctora que aprovecha la periodicidad del refresco: no necesita detectar todos y cada uno de los comandos; en su lugar, detecta desalineaciones y realinea la ejecución del patrón para seguir el ritmo, incluso cuando se pierde un refresco puntual. Este enfoque permite sostener la coherencia a lo largo de miles de tREFI.
Para ilustrar la mejora, los investigadores señalan que gracias a esta sincronización robusta pueden mantener su patrón en perfecto compás con los ciclos internos de TRR, algo que los métodos previos no conseguían sin caer en desfase tras unos cientos de intervalos.
En términos prácticos, esta estabilidad es la que habilita la escalada end‑to‑end en una máquina de escritorio con DDR5, culminando en privilegios de root con parámetros por defecto en tiempos tan agresivos como 109 segundos en su demostración.
Resultados experimentales: 15 DIMMs vulnerables y flips explotables
El equipo evaluó 15 módulos DDR5 de SK Hynix fabricados entre finales de 2021 y finales de 2024. Todos mostraron bit flips con uno de los dos patrones. El patrón corto de 128 tREFI resultó, de media, 2,62× más eficaz que el largo, arrojando del orden de miles de flips por DIMM: el trabajo cita una media aproximada de 4989 flips en sus pruebas.
Esos flips se convirtieron en primitivas reales en tres escenarios ya conocidos: (i) corrupción de PTEs para leer/escribir memoria arbitraria (todos los DIMMs vulnerables); (ii) extracción de claves RSA‑2048 de VMs colocalizadas para romper SSH (en un 73% de los DIMMs vulnerables); y (iii) modificación del binario sudo para elevar privilegios locales (en un 33% de los DIMMs vulnerables).
Además, los autores replican por primera vez en DDR5 la escalada de privilegios del trabajo Rubicon, mostrando tiempos de explotación promedio de 5:19 bajo condiciones de prueba controladas, lo que refuerza la viabilidad práctica del ataque fuera del laboratorio.
La ejecución se apoyó en un sistema con CPU AMD Zen 4 y módulos SK Hynix. El equipo planea expandir pruebas a otros fabricantes y arquitecturas para entender el alcance completo; aun así, la combinación actual ya es representativa de un entorno de escritorio moderno con DDR5.
Como dato de riesgo agregado, las distintas métricas sitúan Phoenix en severidad relevante: CVSS v4 7.1 (High) con vector documentado; CVSS v3 5.5 (Medium) con vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; y CVSS v2 2.1 (Low) con vector AV:L/AC:L/Au:N/C:N/I:P/A:N. El EPSS asociado se estima en 0.00014, reflejando probabilidad de explotación observada en el ecosistema, aunque esa cifra debe interpretarse junto al impacto técnico probado.
Mitigaciones y coste de defenderse hoy
Como medida de choque, los investigadores recomiendan triplicar la tasa de refresco (3×), lo que en sus sistemas detuvo los flips de Phoenix. Dado que tREFI ronda los 1,3 μs, este ajuste implica más operaciones de refresco y, por tanto, un coste de rendimiento medible: en SPEC CPU2017 reportan hasta un 8,4% de sobrecarga.
También señalan que proveedores y OEMs tienen palancas inmediatas: actualizaciones de BIOS/firmware para ajustar políticas de memoria o parámetros de refresco. De hecho, en la ventana de embargo, AMD comunicó la disponibilidad de un update de BIOS para máquinas cliente, si bien los autores no pudieron verificar de forma independiente hasta qué punto mitiga específicamente Phoenix.
Importante: el on‑die ECC no es un “escudo mágico”. Según el paper, las correcciones diferidas permiten que los flips se acumulen si el atacante martillea con un patrón que pasa el filtro de TRR. Por ello, el ODECC no impide, por sí solo, el avance del ataque en DDR5 bajo las condiciones descritas.
Mirando al medio plazo, el sector necesita mitigaciones “de principios” y no respuestas ad‑hoc a cada patrón nuevo. JEDEC ha definido PRAC, pero los autores y Google señalan que los sistemas DDR5 probados no lo incluyen, dejando margen a la evasión. Un despliegue más amplio de mecanismos de conteo por fila y políticas de refresco adaptativas podría elevar la barrera significativamente.
Contexto: otros ataques y el papel de los servidores con ECC
RowHammer ha ido acumulando variantes, cada una presionando en un flanco distinto de la defensa. Además de TRRespass, SMASH, Half‑Double y Blacksmith, investigaciones recientes presentaron OneFlip (cambiar un bit para alterar pesos de modelos DNN y provocar comportamientos indeseados) y ECC.fail (primer ataque end‑to‑end eficaz contra máquinas DDR4 de servidor con memoria ECC, induciendo flips en ubicaciones concretas que burlan la detección/corrección).
En teoría, los servidores cuentan con protecciones extra frente a la corrupción de memoria (como el ECC para rayos cósmicos o RowHammer), pero ECC.fail mostró que, con el estímulo adecuado, también pueden ceder. Phoenix se suma a esa lista desde el frente DDR5 de escritorio, evidenciando que el equilibrio entre densidad, rendimiento y robustez es una línea muy fina.
Incluso fabricantes y ecosistemas consolidados han sido salpicados por investigaciones de este tipo (p. ej., Nvidia o plataformas DDR4), y no es casualidad: a medida que los transistores y celdas se acercan, las interferencias eléctricas y los canales laterales encuentran resquicios que antes no existían.
El aprendizaje es claro: las mitigaciones deben evolucionar con la física del hardware, integrando telemetría y respuestas dinámicas que huyan de supuestos estáticos de muestreo, justo el talón de Aquiles que explota Phoenix en las DDR5 evaluadas.
Divulgación responsable, cronología y recursos
ETH Zürich inició un proceso de divulgación responsable a través del NCSC suizo el 6 de junio de 2025, notificando a SK Hynix, fabricantes de CPU y grandes proveedores cloud. El asunto permaneció bajo embargo hasta el 15 de septiembre de 2025. Poco antes, el 12 de septiembre, AMD informó de un BIOS para equipos cliente, sin verificación independiente por parte de los autores.
El trabajo completo se presentará en el IEEE Symposium on Security and Privacy 2026. El paper y los artefactos (incluyendo PoC y herramientas de test) están disponibles públicamente: puedes consultar el PDF y el repositorio para reproducir pruebas y evaluar tus módulos en laboratorio controlado.
Enlaces útiles: paper en PDF y repositorio de Phoenix en GitHub. Google publicó además una entrada en su Security Blog comentando el alcance y las herramientas de test para DDR5.
Las fichas de vulnerabilidad señalan como fuentes Mitre y NVD, con fecha de publicación y actualización del 15 de septiembre de 2025 bajo el nombre Phoenix. El etiquetado CVE-2025-6202 y sus vectores permiten a equipos de riesgo priorizar y trazar decisiones de mitigación con criterios homogéneos.
Notas de fabricante y consideraciones legales
AMD publicó un descargo de responsabilidad donde recalca que la información técnica puede contener inexactitudes, no ofrece garantías implícitas ni explícitas y no asume responsabilidad por el uso de hardware o software descritos. También recuerda que las marcas AMD, EPYC y Ryzen son propiedad de la compañía, y que las siglas CVE y su logo pertenecen a The MITRE Corporation.
El mismo aviso señala que contenidos de terceros enlazados se proporcionan “tal cual” (AS IS) y su uso corre por cuenta del lector. Este tipo de disclaimers es habitual en documentación técnica y no afecta a la validez de los hallazgos académicos, pero conviene tenerlo presente en despliegues productivos y comunicaciones corporativas.
Qué deben hacer usuarios, administradores y proveedores
Si gestionas equipos con DDR5 de SK Hynix, el primer paso es inventariar módulos y revisar versiones de BIOS/firmware disponibles para tu plataforma. Muchos OEM pueden publicar ajustes que eleven el umbral de seguridad mientras llegan mitigaciones más de fondo.
En segundo lugar, evalúa en laboratorio cerrado (nunca en producción) la susceptibilidad con los artefactos públicos de Phoenix, especialmente si operas entornos multi‑tenant o cargas sensibles (p. ej., claves criptográficas en memoria). La herramienta de ETH/Google incluye utilidades de test pensadas para DDR5, con recomendaciones explícitas de uso responsable.
Si tus pruebas evidencian flips, valora activar el 3× de refresco en los sistemas más críticos, asumiendo el coste de rendimiento. En cargas donde el SLA lo permita, ese 8,4% medido en SPEC puede ser un precio razonable frente a la posibilidad de escaladas locales o extracción de secretos entre inquilinos.
En cloud privado o entornos con VMs colocalizadas, endurece límites de afinidad y aislamiento, y minimiza la exposición de secretos de alto valor en memoria cuando haya sospecha de co‑residencia no confiable. Acompaña esto con monitorización y reglas de respuesta ante patrones de acceso a memoria anómalos.
Por último, mantente atento a futuras actualizaciones del estándar (p. ej., PRAC) y al trabajo de fabricantes para integrar protecciones basadas en conteo por fila y políticas de refresco adaptativas. Phoenix demuestra que, sin ese salto cualitativo, la industria seguirá jugando al gato y al ratón con cada nueva variación de patrón.
Aunque el vector principal sea local (AV:L en CVSS v3), el impacto en integridad es alto y la ventana de explotación corta, con evidencias de escalada a root, robo de claves RSA‑2048 e manipulación de binarios críticos. Combinar hardening inmediato, pruebas controladas y vigilancia de parches es, hoy, la estrategia más sensata.
El caso Phoenix pone de relieve cómo pequeños desajustes en la estrategia de muestreo de TRR pueden arruinar defensas teóricamente robustas. Con sincronización auto‑correctora, patrones de 128 y 2608 tREFI, paralelización por bancos y un cuidado alineamiento de refresco (solo 2 de 128 offsets son válidos, elevando la probabilidad al 25% al explotar cuatro bancos a la vez), este ataque consolida que DDR5 no es un puerto seguro por defecto frente a RowHammer. Entre la contundencia de los resultados experimentales, la posibilidad de explotación end‑to‑end en minutos y el coste asumible de mitigaciones temporales (3× refresh), el mensaje para equipos técnicos es claro: merece la pena actuar ya, sin esperar a soluciones perfectas, a la vez que se empuja a la industria a integrar defensas de principios como PRAC y nuevas políticas de refresco más inteligentes.
