- GPUHammer adapta la vulnerabilidad Rowhammer a la memoria de las GPUs, provocando inversiones de bit en GDDR6 y corrompiendo modelos de IA sin síntomas visibles en el sistema.
- En pruebas sobre una NVIDIA RTX A6000, el ataque redujo la precisión de modelos como ResNet-20 en ImageNet del 80% a aproximadamente el 0,1%, dejando las cargas de IA prácticamente inútiles.
- NVIDIA recomienda activar ECC para mitigar GPUHammer, asumiendo una pérdida de rendimiento cercana al 10% y una reducción de memoria útil del 6,25%, además de reforzar el aislamiento en entornos cloud.
- GPUHammer, junto a variantes como CrowHammer, evidencia que la seguridad de la IA debe abordar también vulnerabilidades físicas de hardware, con impacto en cumplimiento normativo y riesgos críticos en sectores regulados.
La aparición de GPUHammer ha encendido todas las alarmas en el mundo de la ciberseguridad y de la inteligencia artificial. Lo que parecía una vulnerabilidad teórica más ligada a la memoria DRAM de los ordenadores se ha colado de lleno en el corazón de las GPUs modernas, capaces de dejar inválidos modelos de IA que hasta hace nada presumían de una precisión altísima.
Esta técnica, heredera directa de los clásicos ataques Rowhammer sobre memoria DRAM, demuestra que las tarjetas gráficas ya no son solo aceleradores de cálculo, sino una nueva superficie de ataque crítica. Y lo hace de la peor forma posible: logrando que un modelo de IA pase de acertar alrededor del 80% de las veces a quedarse en un ridículo 0,1%, sin que el sistema salte por los aires ni muestre errores evidentes.
Qué es GPUHammer y por qué supone un problema tan serio
GPUHammer es la primera variante documentada de Rowhammer diseñada específicamente para atacar la memoria de las GPUs. En lugar de centrarse en la DRAM tradicional de la CPU, este método se dirige a la memoria de vídeo (como GDDR6) que emplean tarjetas gráficas profesionales y de alto rendimiento, con un objetivo muy claro: corromper silenciosamente los datos que residen en esa memoria, en especial los parámetros internos de los modelos de inteligencia artificial.
El ataque se ha demostrado de forma práctica en una NVIDIA RTX A6000 con 48 GB de memoria GDDR6, una GPU profesional muy utilizada en centros de datos, laboratorios de investigación y empresas que entrenan o despliegan modelos de IA avanzados. Mediante un patrón cuidadosamente diseñado de accesos a memoria, los investigadores lograron provocar más de 3.800 inversiones de bit (bit flips) en la VRAM de la tarjeta sin necesidad de privilegios de administrador.
Esta forma de ataque es especialmente peligrosa porque no busca romper el sistema operativo ni robar archivos de forma directa, sino algo más sutil y devastador: degradar la fiabilidad de los modelos de IA hasta hacerlos prácticamente inútiles, mientras todo sigue aparentando normalidad en el servidor o en la máquina afectada.
En vez de causar un cuelgue, una pantalla azul o una caída del servicio, GPUHammer altera silenciosamente los bits de la memoria donde se almacenan pesos, activaciones o datos intermedios de la IA. El resultado es que el modelo empieza a responder mal, a cometer errores grotescos en clasificación de imágenes, detección de fraude, diagnóstico médico o conducción autónoma, y nadie sospecha que el origen está en un ataque físico contra la memoria de la GPU.
Para rematar, el exploit puede ejecutarse desde un proceso sin privilegios elevados, lo que hace que en entornos multiusuario o en la nube un atacante pueda intentar afectar a las cargas de trabajo de otros inquilinos que comparten la misma GPU, sin tener acceso directo a sus datos ni a sus modelos.
Cómo funciona un ataque Rowhammer y su adaptación a GPUHammer
La base técnica de GPUHammer está en Rowhammer, una vulnerabilidad física de la memoria DRAM descubierta hace años. Rowhammer consiste en “martillear” (acceder de forma repetitiva y muy intensa) una o varias filas de celdas de memoria con operaciones de lectura o escritura. Este patrón provoca interferencias eléctricas en las filas vecinas, que pueden hacer que algunos bits cambien de estado de forma espontánea, es decir, que un 0 pase a ser un 1 o viceversa.
En DRAM tradicional, este fenómeno ya se ha utilizado para montar exploits que permiten escalar privilegios, alterar tablas de páginas o modificar datos sensibles sin tener acceso directo a ellos. Variantes como ZenHammer, por ejemplo, afectaron a procesadores AMD Ryzen y EPYC (Zen 2 y Zen 3), mientras que otras investigaciones han apuntado a módulos DDR5 de determinados fabricantes. Rowhammer también se ha combinado con vulnerabilidades como Spectre en ataques como SpecHammer, capaces de insertar valores maliciosos en memoria y luego explotarlos mediante ejecución especulativa.
La particularidad de GPUHammer es que traslada este mismo concepto a la memoria de vídeo de las GPUs, como la GDDR6. Sin embargo, hacerlo no ha sido trivial: las memorias de las tarjetas gráficas funcionan a velocidades mucho mayores, con latencias distintas y con mecanismos internos de protección (como Target Row Refresh, TRR) que, en teoría, deberían mitigar este tipo de problemas.
Para superar estos obstáculos, los investigadores tuvieron que realizar ingeniería inversa de los mapeos físicos de la memoria de la GPU, averiguar cómo se organizan los bancos, filas y columnas en la GDDR6 y cómo se traduce la dirección virtual que ve el programa a la disposición física real en los chips. Solo así pudieron diseñar patrones de acceso que golpearan repetidamente las filas adecuadas para inducir bit flips en las filas vecinas.
Otro reto importante fue sincronizar los accesos con las operaciones de refresco de la memoria y maximizar el número de hilos que martilleaban simultáneamente, aprovechando la enorme capacidad de ejecución en paralelo de las GPUs modernas. En algunos experimentos se llegaron a lanzar hasta 500.000 accesos concurrentes para aumentar la probabilidad de inversión de bits.
Además, la implementación de GPUHammer tuvo que lidiar con mecanismos de mitigación como Target Row Refresh (TRR), que detectan patrones sospechosos de acceso repetitivo y fuerzan el refresco de filas adyacentes. Aun así, se ha demostrado que es posible conseguir bit flips incluso con TRR activo, lo que cuestiona la eficacia de estas protecciones en entornos de alta exigencia como la IA.
Impacto devastador en la precisión de la inteligencia artificial
El punto más demoledor de GPUHammer es su efecto sobre los modelos de redes neuronales profundas (DNN). En la práctica, basta con corromper unos pocos bits estratégicos de los pesos de un modelo entrenado para que su comportamiento se vuelva impredecible o, directamente, inútil para su propósito.
En las pruebas realizadas con la NVIDIA RTX A6000, los investigadores utilizaron, entre otros, un modelo de clasificación de imágenes del tipo ResNet-20 entrenado sobre ImageNet. Antes del ataque, la precisión rondaba el 80%, una cifra razonable para este tipo de tareas. Tras ejecutar GPUHammer y provocar miles de bit flips en la memoria de la GPU, la precisión cayó a aproximadamente un 0,1%, lo que equivale prácticamente a predicciones aleatorias.
Algo similar se comprobó con otros modelos preentrenados: basaba con introducir un único cambio de bit de forma dirigida para derribar entre un 56% y un 80% la precisión, dejando los modelos prácticamente inservibles para tareas de inferencia. En esencia, la GPU afectada pasaba de ser una herramienta de cómputo de alto rendimiento a convertirse en poco más que un pisapapeles caro.
Lo más inquietante es que todo esto ocurre sin que el sistema reporte errores críticos. No se produce un fallo de segmentación, no se corrompe un archivo en disco de forma evidente, ni salta una alerta clara en el sistema operativo. Lo único que cambia, y de forma drástica, es el resultado de los cálculos del modelo de IA. Si nadie está monitorizando de cerca la calidad de las predicciones, el ataque puede pasar totalmente desapercibido durante un largo periodo.
Ese carácter “sigiloso” convierte a GPUHammer en una herramienta perfecta para el sabotaje de infraestructuras de IA. Un atacante no necesita extraer datos ni tomar el control del sistema; le basta con degradar la precisión de los modelos que sustentan servicios críticos para causar daños económicos, reputacionales o incluso poner en riesgo la seguridad física de personas.
Entre las aplicaciones especialmente sensibles a este tipo de corrupción silenciosa están los vehículos autónomos, los sistemas de diagnóstico médico asistidos por IA, los motores de detección de fraude en banca y seguros, así como plataformas de IA en el borde (edge) o sistemas financieros algorítmicos. Un solo modelo decisorio degradado puede desencadenar una cascada de decisiones erróneas con consecuencias graves.
Entornos afectados, GPUs vulnerables y papel de la nube
GPUHammer pone de manifiesto que las GPUs profesionales compartidas en entornos cloud son objetivos especialmente atractivos. En plataformas de computación en la nube, escritorios virtuales o servicios de inferencia como servicio, varios clientes pueden compartir una misma GPU física mediante virtualización o particionado lógico.
En este contexto, un usuario malicioso con acceso legítimo a un entorno GPU (por ejemplo, a través de un contenedor, una máquina virtual o una sesión remota) podría ejecutar un kernel especialmente diseñado para provocar bit flips en zonas de memoria de otros inquilinos. No necesita ver sus datos ni tener permisos sobre sus procesos; solo debe ser capaz de generar los patrones de acceso adecuados en la VRAM.
Este escenario abre la puerta a riesgos entre inquilinos que muchas arquitecturas no estaban teniendo en cuenta en su modelo de amenazas. Hasta ahora, se tendía a asumir que la GPU era un acelerador “compartible” siempre que se aislaran bien los procesos a nivel de sistema operativo y de hipervisor. GPUHammer demuestra que hay que mirar más abajo, al propio hardware de memoria y a cómo se gestionan sus refrescos y correcciones de errores.
En cuanto a los modelos concretos de GPU, la investigación ha mostrado que la NVIDIA RTX A6000 con GDDR6 es vulnerable al ataque, mientras que otras tarjetas como la RTX 3080 parecen resistirse, probablemente por diferencias en el proveedor de memoria GDDR, el mapeo interno de direcciones o las medidas de mitigación implementadas en esos chips.
NVIDIA, por su parte, ha reconocido públicamente el problema y ha emitido avisos de seguridad recomendando medidas de mitigación. Las tarjetas more modernas como la NVIDIA H100 o hipotéticas gamas como la RTX 5090, que integran mecanismos de corrección de errores (ECC) directamente en el propio chip de memoria o en el subsistema de la GPU, no se consideran vulnerables a esta variante concreta de GPUHammer.
Todo esto ocurre en un contexto donde, desde hace años, se vienen descubriendo múltiples variantes de Rowhammer que afectan tanto a DRAM de CPU como a memorias DDR5 concretas. GPUHammer se suma a una lista cada vez más larga de ataques físicos a memoria que obligan a fabricantes, proveedores cloud y empresas a replantear sus estrategias de seguridad.
Respuesta de NVIDIA y mitigaciones recomendadas
La recomendación principal de NVIDIA frente a GPUHammer es clara: activar ECC (Error-Correcting Code) en las GPUs afectadas. ECC permite detectar y, en muchos casos, corregir errores de bit únicos provocados por fluctuaciones eléctricas, radiación cósmica o, como en este caso, ataques intencionados contra la memoria.
En sistemas que utilicen GPUs como la RTX A6000, es posible habilitar ECC mediante comandos de la herramienta de gestión de NVIDIA. Una vez activado, el sistema debe reiniciarse para que la configuración surta efecto. A partir de ese momento, la GPU será capaz de detectar y corregir un gran número de bit flips antes de que afecten a los datos utilizados por los modelos de IA.
Sin embargo, esta protección tiene un precio: NVIDIA ha reconocido que la activación de ECC puede reducir el rendimiento de cargas de trabajo de aprendizaje automático e inferencia en torno a un 10%, además de disminuir la cantidad de memoria disponible aproximadamente un 6,25%, ya que parte de la capacidad se reserva para los bits de corrección.
Por este motivo, muchas organizaciones se plantean habilitar ECC solo en nodos de entrenamiento o en cargas de trabajo especialmente críticas, como aquellas que afectan a sanidad, finanzas, defensa o sistemas autónomos. También se recomienda supervisar de manera proactiva los registros del sistema (por ejemplo, /var/log/syslog o dmesg en Linux) para detectar eventos de corrección de errores de memoria que puedan indicar intentos de ataque o inestabilidades inusuales.
Aparte de ECC, los fabricantes y operadores de infraestructuras pueden adoptar medidas adicionales de endurecimiento: actualización continua de firmware y controladores, mejora de los hipervisores y mecanismos de sandboxing, segmentación estricta de cargas de trabajo de distintos clientes, y monitorización de integridad de memoria y comportamiento anómalo de modelos de IA.
En algunos casos, las correcciones más profundas pueden requerir cambios en la microarquitectura de la GPU o en la forma en que se refresca la DRAM. Esto implica nuevas generaciones de hardware con mitigaciones específicas, algo que lleva tiempo y exige coordinación entre fabricantes de chips, diseñadores de GPUs y proveedores de servicios en la nube.
Relación con otras vulnerabilidades: CrowHammer y el ecosistema Rowhammer
GPUHammer no llega solo. En paralelo, otro equipo de investigación ha presentado CrowHammer, una variante capaz de atacar sistemas criptográficos poscuánticos. En este caso, el blanco ha sido Falcon (FIPS 206), un esquema de firma digital poscuántico seleccionado por el NIST para su estandarización.
En CrowHammer, los investigadores demostraron que un único cambio de bit bien dirigido en la tabla de distribución de Falcon puede sesgar las salidas del algoritmo lo suficiente como para permitir la recuperación completa de la clave privada, siempre que se disponga de varios cientos de millones de firmas. Con un mayor número de distorsiones, la cantidad de firmas necesarias se reduce todavía más.
Este tipo de resultados pone sobre la mesa que ni siquiera los algoritmos diseñados para resistir la computación cuántica están a salvo si la infraestructura hardware sobre la que se ejecutan presenta vulnerabilidades físicas como Rowhammer. No importa lo robusto que sea el esquema criptográfico en el papel si los bits en memoria pueden ser manipulados a voluntad por un atacante.
GPUHammer se suma así a un ecosistema cada vez más sofisticado de técnicas que explotan el comportamiento físico de la memoria y la ejecución especulativa, combinándose en ocasiones con fallos como Spectre o Meltdown. La moraleja es clara: no basta con securizar el software y los datos; también hay que considerar el hardware como una superficie de ataque de primer nivel.
Para sectores con altos requisitos de seguridad y transparencia -sanidad, finanzas, defensa, sistemas autónomos-, estos avances suponen una llamada a revisar los marcos de cumplimiento y auditoría, integrando la memoria de GPU, las vulnerabilidades a nivel de chip y las medidas de mitigación como parte estándar de cualquier evaluación de riesgos.
Implicaciones para empresas, regulaciones y estrategias de seguridad
La corrupción silenciosa de modelos de IA mediante GPUHammer plantea retos que van más allá del plano técnico. A nivel de cumplimiento normativo, una decisión automatizada errónea basada en un modelo dañado puede violar normas de seguridad, integridad de datos y explicabilidad, especialmente en jurisdicciones con marcos estrictos como la Ley de IA de la Unión Europea o estándares como ISO/IEC 27001.
Las organizaciones que dependen intensivamente de GPUs para entrenar y desplegar modelos críticos deben incluir la memoria de GPU y sus posibles fallos físicos dentro de su postura de seguridad. Esto implica auditar de forma periódica no solo los datos y el código, sino también los patrones de actividad en la VRAM, los logs de errores corregidos por ECC y el comportamiento de precisión de los modelos en producción.
Además, la adopción masiva y acelerada de herramientas de IA, incluida la incorporación de agentes de IA autónomos, complica aún más el escenario. Estos agentes permiten ejecutar campañas de ataque prolongadas, automatizar análisis de sistemas objetivo, generar código de explotación y procesar grandes volúmenes de datos robados con una eficiencia que ningún equipo humano puede igualar.
Con la configuración adecuada, incluso grupos con poca experiencia o recursos limitados podrían lanzar ataques a gran escala contra infraestructuras de IA, aprovechando vulnerabilidades como GPUHammer para sabotear modelos, degradar servicios o desencadenar decisiones automatizadas que generen caos operativo o beneficios económicos ilícitos.
Para hacer frente a este panorama, las empresas deben reevaluar sus arquitecturas defensivas, muchas de las cuales fueron diseñadas pensando en ataques “a ritmo humano” y no en ofensivas automatizadas y continuas. Esto incluye reforzar el aislamiento entre cargas de trabajo en la nube, establecer verificaciones periódicas de integridad de modelos, desplegar redundancias y sistemas de votación entre diferentes instancias de IA, y contar con planes de respuesta específicos ante corrupción de modelos.
Servicios especializados en ciberseguridad para entornos de IA y GPU pueden ser de gran ayuda. Firmas con experiencia en auditorías de seguridad orientadas a GPU, pruebas de penetración específicas para cargas aceleradas y diseño de arquitecturas seguras en AWS, Azure u otras plataformas permiten identificar puntos débiles, proponer configuraciones robustas de ECC y aislamiento, y desplegar monitorización inteligente de modelos y memoria.
En un escenario donde las amenazas evolucionan constantemente y ataques como Rowhammer, GPUHammer o CrowHammer se adaptan a nuevas superficies, la combinación de desarrollo de software responsable, arquitectura cloud segura y vigilancia proactiva deja de ser opcional y pasa a convertirse en un requisito para operar con IA de forma segura.
Todo lo que hemos visto alrededor de GPUHammer deja claro que la revolución de la inteligencia artificial se sostiene sobre un hardware que no es infalible; entender cómo un simple cambio de bit en la memoria de una GPU puede tumbar la precisión de un modelo, asumir el coste de activar ECC cuando toque, reforzar el aislamiento entre cargas y mirar la GPU no solo como un acelerador, sino como un vector de ataque más, es ya parte del trabajo imprescindible para cualquiera que dependa de la IA en producción.
