Ataque GPUHammer: la nueva amenaza de hardware contra la inteligencia artificial

La aparición de GPUHammer ha encendido todas las alarmas en el mundo de las amenazas de ciberseguridad y la inteligencia artificial. Esta técnica, inspirada en los ataques RowHammer clásicos sobre memoria DRAM, se ha trasladado por primera vez de forma práctica al terreno de las GPUs modernas, poniendo en jaque la fiabilidad de los modelos de IA que se ejecutan sobre tarjetas gráficas profesionales y de centros de datos.

Lo inquietante no es solo que logre corromper silenciosamente la memoria de la GPU, sino que un único cambio de bit puede bastar para destrozar la precisión de redes neuronales profundas que hasta ese momento funcionaban a la perfección. Sin pantallazos azules, sin errores visibles y sin necesidad de permisos de administrador, GPUHammer se cuela como un invitado incómodo en la fiesta de la IA, demostrando que la seguridad de estos sistemas no puede limitarse al software o a los datos: el hardware también es un objetivo directo.

Qué es GPUHammer y cómo funciona este ataque sobre GPUs

GPUHammer es una variante de la familia de ataques RowHammer, pero enfocada específicamente en las memorias de vídeo GDDR6 que montan ciertas GPUs de Nvidia, como la RTX A6000. RowHammer, en su forma original, explota un fallo físico en los chips de memoria DRAM: al acceder de manera muy rápida y repetitiva a una fila concreta de celdas, se generan interferencias eléctricas que acaban provocando que los bits de las filas vecinas cambien de valor (de 0 a 1 o de 1 a 0).

En el contexto de las GPUs, GPUHammer traslada este concepto a la memoria onboard de la tarjeta gráfica. Mediante un patrón cuidadosamente diseñado de accesos masivos en paralelo, un proceso malicioso que se ejecuta sobre la GPU puede “martillear” determinadas direcciones físicas de memoria hasta forzar esas inversiones de bits en regiones adyacentes que pertenecen a otros procesos o a estructuras críticas, como los pesos de un modelo de IA.

Lo realmente peligroso de este tipo de ataque es que se trata de un problema puramente de hardware, no de software. No estamos ante un bug que se parchea con una actualización del sistema operativo; hablamos de cómo están construidos y cómo se comportan físicamente los chips de memoria. Por eso, las soluciones son complejas, costosas y, en muchos casos, pasan por cambios de diseño en futuras generaciones de GPUs, obligando a traducir el riesgo técnico al valor de negocio.

Además, los aceleradores gráficos suelen carecer de algunas protecciones habituales en CPUs, como controles de acceso finos a nivel de instrucción o ciertos chequeos de paridad y mecanismos de verificación robustos. Este menor “endurecimiento” de las GPUs abre la puerta a ataques de bajo nivel cuando se comparten entre múltiples usuarios, algo muy habitual en plataformas cloud, VDI o infraestructuras de IA para empresas.

GPUHammer ha demostrado también que es posible sortear defensas teóricamente sólidas como Target Row Refresh (TRR), una técnica incluida en muchas memorias modernas para mitigar los efectos de RowHammer refrescando filas vecinas cuando detecta actividad intensa en una determinada fila. Aun con TRR presente, los investigadores han logrado inducir miles de bit flips en memoria GDDR6.

Detalles técnicos del ataque y resultados en modelos de IA

El caso de estudio más citado es el de la Nvidia RTX A6000 con 48 GB de GDDR6, una GPU profesional basada en arquitectura Ampere muy utilizada en centros de datos y estaciones de trabajo avanzadas. Los investigadores de la Universidad de Toronto, entre otros, se centraron en esta tarjeta para demostrar la viabilidad práctica de GPUHammer.

Para llevar a cabo el ataque, primero tuvieron que reconstruir cómo se organiza físicamente la memoria de la GPU: mapeos de filas, bancos, canales, etc. Esta parte no está documentada de manera abierta por los fabricantes, así que recurrieron a técnicas de ingeniería inversa para comprender el layout interno de la GDDR6 y encontrar los patrones de acceso que más probabilidades tenían de inducir inversiones de bits.

Una vez identificado el mapa de memoria, diseñaron kernels CUDA capaces de realizar accesos masivos y paralelos a ciertas direcciones, llegando a disparar hasta 500.000 accesos concurrentes para maximizar el estrés eléctrico sobre las filas objetivo. También ajustaron el timing del ataque para sincronizarse con las operaciones de refresco de memoria, lo que les permitió sortear mitigaciones como TRR y aumentar significativamente la tasa de bit flips.

Los experimentos se centraron en modelos de clasificación de imágenes, como ResNet-20 entrenado sobre ImageNet. En el escenario control, sin ataque, el modelo alcanzaba alrededor de un 80 % de precisión top-1, una cifra razonable para este tipo de arquitectura y conjunto de datos. Tras aplicar GPUHammer e introducir más de 3.800 inversiones de bits en los pesos y estructuras internas del modelo, la precisión se desplomó a aproximadamente un 0,1 %, es decir, el modelo pasó de ser útil a comportarse prácticamente como un generador de respuestas aleatorias.

En otros ensayos, utilizando hasta cinco modelos distintos preentrenados también sobre ImageNet, los investigadores observaron que un solo bit flip podía bajar la precisión entre un 56 % y un 80 %, lo que ilustra la fragilidad extrema de las redes neuronales profundas frente a alteraciones mínimas en sus parámetros. No hace falta un sabotaje masivo; una manipulación quirúrgica de bits concretos en la memoria ya es suficiente para inutilizar el sistema.

Es importante resaltar que la GPU no muestra síntomas evidentes de fallo: no hay cuelgues, ni errores de driver, ni reinicios inesperados. Desde el punto de vista del sistema operativo, todo va bien. El problema se limita a que el modelo deja de acertar, pero eso puede atribuirse a “ruido”, a cambios en los datos o a errores en otra parte del pipeline, dificultando así la detección rápida del ataque.

Modelos de GPU afectados, diferencias entre arquitecturas y papel de la memoria

Hasta ahora, GPUHammer se ha demostrado de manera concluyente en la Nvidia RTX A6000 con memoria GDDR6. En cambio, al intentar replicar el ataque sobre una RTX 3080, los resultados no fueron los mismos: los investigadores no lograron la misma tasa de bit flips ni un impacto comparable en los modelos de IA. La principal hipótesis es que las diferencias residen en los proveedores de memoria GDDR, sus esquemas de mapeo interno y las mitigaciones específicas que implementa cada fabricante en sus chips.

Este detalle deja claro que la vulnerabilidad está muy ligada a las características físicas y al diseño de las memorias de vídeo. La GDDR6 utilizada en algunas tarjetas puede ser más propensa a este tipo de perturbaciones, mientras que generaciones más recientes como GDDR7 o memorias HBM3 empleadas en GPUs de gama muy alta para centros de datos integran corrección de errores directamente en el chip, reduciendo de forma drástica la superficie de ataque para técnicas tipo RowHammer.

Nvidia ha reconocido el problema y ha publicado avisos de seguridad recomendando habilitar ECC (Error Correcting Code) allí donde esté disponible. En el caso de la A6000, ECC puede activarse con el comando “nvidia-smi -e 1” seguido de un reinicio del sistema, y su estado puede verificarse con “nvidia-smi -q | grep ECC”. Habilitar ECC permite detectar y corregir automáticamente muchos de los errores de memoria que GPUHammer intenta provocar.

Eso sí, esta defensa tiene un coste: activar ECC en la RTX A6000 provoca una pérdida de rendimiento en cargas de IA de alrededor del 10 % y reduce la memoria utilizable en aproximadamente un 6,25 %. Por ello, Nvidia sugiere, en algunos escenarios, activar ECC solo en nodos de entrenamiento o en cargas de trabajo especialmente sensibles, aunque desde un punto de vista de seguridad pura lo ideal sería contar con ECC siempre que se procesen tareas críticas.

Las GPUs de última generación como Nvidia H100 o la futura RTX 5090 incorporan mecanismos de corrección de errores directamente en el hardware y en las memorias HBM o GDDR7 que emplean, lo que las hace no vulnerables, al menos en teoría, a esta variante concreta de GPUHammer tal y como se ha descrito hasta la fecha. Aun así, los propios investigadores ya están explorando nuevos métodos para intentar bordear también estas defensas de próxima generación.

Impacto de GPUHammer en la inteligencia artificial y sectores críticos

El objetivo prioritario de GPUHammer es la corrupción silenciosa de modelos de IA que residen en la memoria de la GPU, especialmente redes neuronales profundas con millones de parámetros. A diferencia de otros tipos de ataques que manipulan datos de entrada o intentan robar información, aquí lo que se busca es degradar la calidad de las predicciones sin dejar rastro evidente en el sistema.

Esta amenaza es especialmente grave en aplicaciones donde la IA se ha convertido en un componente central para la toma de decisiones. Hablamos de sistemas de diagnóstico médico asistido, motores de detección de fraude financiero, algoritmos que controlan vehículos autónomos, plataformas de análisis de riesgo o sistemas de IA en el perímetro (edge) que procesan datos sensibles en tiempo real. Un ataque exitoso podría provocar diagnósticos erróneos, bloqueos o autorizaciones indebidas de transacciones, decisiones de conducción peligrosas o fallos en sistemas críticos de infraestructura.

Además, GPUHammer se adapta particularmente bien a entornos multiusuario y de GPU compartida, como los servicios cloud, escritorios virtuales (VDI) o plataformas de inferencia donde varias organizaciones comparten los mismos aceleradores físicos. Un inquilino potencialmente malicioso podría ejecutar kernels diseñados para martillear la memoria de la GPU y provocar bit flips en regiones utilizadas por otros inquilinos, sin necesidad de acceder directamente a sus datos ni saltar barreras de usuario tradicionales.

Esto introduce una nueva clase de riesgos entre inquilinos (multi-tenant) que hasta ahora apenas se tenían en cuenta en el modelo de amenazas de muchas nubes públicas. La eficiencia económica de compartir GPUs entre varios clientes viene acompañada de una mayor exposición a ataques de bajo nivel que actúan sobre la arquitectura de memoria de vídeo.

Desde el punto de vista regulatorio, la corrupción invisible de modelos de IA tiene un impacto directo sobre el cumplimiento de normativas como ISO/IEC 27001, la futura Ley de IA de la Unión Europea o regulaciones sectoriales en sanidad, finanzas, defensa y transporte, y forma parte del panorama de ciberseguridad. Si un modelo toma decisiones críticas basadas en parámetros dañados, la organización podría estar incumpliendo requisitos de integridad de datos, trazabilidad, explicabilidad y gestión de riesgos, incluso aunque la intrusión no haya dejado huellas evidentes en logs de aplicación.

Relación con otros ataques: RowHammer, SpecHammer y CrowHammer

GPUHammer no aparece de la nada; es la evolución lógica de una larga serie de investigaciones sobre RowHammer y ataques a nivel de hardware. RowHammer, descubierto hace años en memorias DRAM convencionales, ya había dado lugar a numerosas variantes, como ZenHammer (orientado a ciertas arquitecturas de CPU de AMD, concretamente Zen 2 y Zen 3), o ataques contra módulos DDR5 de fabricantes como SK Hynix documentados en 2025.

En 2022, equipos de la Universidad de Michigan y Georgia Tech combinaron RowHammer con vulnerabilidades de ejecución especulativa tipo Spectre para crear SpecHammer, un ataque que aprovechaba tanto cambios de bits en memoria como la capacidad de las CPUs modernas para ejecutar instrucciones especulativamente. SpecHammer permitía insertar valores maliciosos en la memoria de la víctima, lo que a su vez facilitaba ataques especulativos de canal lateral.

Más recientemente, se ha presentado CrowHammer, una variante orientada a la criptografía poscuántica. Investigadores de NTT Social Informatics Laboratories y CentraleSupélec lograron, mediante inversiones dirigidas de bits, recuperar la clave privada del esquema de firma Falcon (FIPS 206), seleccionado por el NIST para su estandarización. Bastaba con alterar un bit concreto en la tabla de distribución de Falcon para sesgar suficientemente la salida y, con varios cientos de millones de firmas, extraer por completo la clave criptográfica.

GPUHammer se suma a esta tendencia mostrando que las GPUs también son terreno fértil para RowHammer. Es la primera técnica documentada que consigue provocar bit flips en memoria GDDR6 onboard de GPUs y abre la puerta a que aparezcan nuevas variantes adaptadas a otros modelos de tarjeta, otros tipos de memoria o incluso combinadas con ataques de canal lateral específicos de las arquitecturas gráficas.

Todo ello pone de manifiesto que la seguridad de los sistemas modernos no puede limitarse a parchear vulnerabilidades de software o a proteger las comunicaciones. La superficie de ataque se ha desplazado hacia las capas físicas del hardware, y las memorias de vídeo, hasta hace poco consideradas un componente “opaco” desde el punto de vista de la seguridad, se han convertido en un vector crítico que hay que vigilar.

Respuesta de Nvidia y medidas de mitigación recomendadas

Nvidia ha publicado avisos de seguridad reconociendo el riesgo que representa GPUHammer y recomendando a sus clientes que adopten medidas de mitigación inmediatas. La más directa y efectiva es habilitar ECC (Error Correcting Code) en las GPUs compatibles, de forma que los errores de memoria inducidos por el ataque puedan ser detectados y corregidos antes de que afecten a los modelos.

La activación de ECC puede realizarse con el comando “nvidia-smi -e 1” seguido de un reinicio del equipo. Para comprobar el estado de ECC en una GPU, se puede utilizar “nvidia-smi -q | grep ECC”. Nvidia sugiere que, en escenarios con limitaciones de rendimiento, se considere activar ECC principalmente en nodos dedicados a entrenamiento o en cargas de trabajo de IA donde la integridad de los resultados sea prioritaria frente a la máxima performance bruta.

Además de ECC, se recomienda monitorizar los registros del sistema (por ejemplo, /var/log/syslog o dmesg en sistemas Linux) en busca de mensajes que indiquen correcciones de errores de memoria. Un incremento inusual en este tipo de eventos podría ser un indicio de que se está intentando explotar una vulnerabilidad tipo GPUHammer o de que la memoria está sufriendo perturbaciones anómalas que exigen una investigación más a fondo.

Desde la perspectiva de la arquitectura de sistemas, es clave reducir la exposición en entornos multiusuario: aplicar políticas estrictas de aislamiento de cargas de trabajo en la nube, limitar el sharing de GPUs entre inquilinos con distintos niveles de confianza, endurecer hipervisores y mecanismos de sandboxing, y establecer cuotas y controles sobre el uso intensivo de la memoria de vídeo por parte de procesos no confiables.

En algunos casos, será necesario plantear cambios más profundos, desde actualizaciones de firmware y drivers hasta rediseños de cómo se gestiona el refresco de la DRAM o la introducción de nuevas técnicas de paridad y corrección de errores en futuras generaciones de GPUs. Muchos de estos ajustes ya se están viendo en modelos avanzados como H100 o en memorias HBM3 y GDDR7, que integran ECC en el propio chip para neutralizar los efectos de perturbaciones como las que explota RowHammer.

Recomendaciones prácticas para empresas que usan IA en GPU

Para organizaciones que dependen de GPUs para inferencia y entrenamiento de modelos de IA, ataques como GPUHammer son una llamada de atención clara. No basta con proteger APIs y bases de datos; hay que incluir la memoria de GPU y su arquitectura de acceso en el análisis de riesgos y en las auditorías de seguridad.

Un primer paso razonable es revisar la configuración de servicios en la nube (por ejemplo, en AWS o Azure) para minimizar el uso compartido de GPUs entre clientes de distinta naturaleza y asegurarse de que se utilizan instancias y opciones de aislamiento acordes al nivel de criticidad de los proyectos de IA. También es recomendable habilitar ECC en las GPUs cloud cuando esté soportado, incluso si eso supone pagar un pequeño peaje de rendimiento.

Otra medida esencial es implementar mecanismos de monitorización y detección de anomalías tanto a nivel de hardware (errores de memoria, bit flips corregidos) como a nivel de modelo (caídas bruscas de precisión, cambios inesperados en la distribución de outputs, comportamientos inestables). En entornos avanzados, incluso se pueden desplegar agentes de IA específicos para vigilar otros componentes de IA y disparar alertas cuando detecten síntomas compatibles con corrupción de parámetros.

En el terreno de la arquitectura, es recomendable introducir redundancias y verificaciones de integridad sobre los modelos: replicar pesos críticos en múltiples GPUs, realizar checksums periódicos de los ficheros de modelo en reposo, validar la coherencia de los parámetros cargados en memoria antes de producción o ejecutar test suites automáticas de calidad de inferencia como parte del ciclo de despliegue continuo.

Empresas especializadas en desarrollo de software a medida, ciberseguridad e IA para empresas, como las que ofrecen servicios sobre AWS y Azure, pueden proporcionar auditorías de seguridad orientadas a entornos GPU, pruebas de penetración específicas para cargas aceleradas por GPU y diseño de arquitecturas cloud que minimicen el impacto operativo de este tipo de amenazas. Integrar también soluciones de inteligencia de negocio (por ejemplo, con Power BI) para visualizar métricas de seguridad y rendimiento permite tomar decisiones más informadas y reaccionar con mayor rapidez ante incidentes.

En un escenario en el que ya se han visto modelos de lenguaje ayudando a atacantes a encontrar fallos zero-day, y donde incluso grandes proveedores han tenido que reconocer intentos de explotación asistidos por IA, la combinación de IA ofensiva y debilidades de hardware como GPUHammer dibuja un panorama en el que la defensa debe ser igual de creativa y proactiva que el ataque.

La irrupción de GPUHammer demuestra que la revolución de la inteligencia artificial descansa sobre una infraestructura cuya seguridad física y lógica no puede darse por supuesta. Entender cómo ataques de inversión de bits pueden convertir una GPU de gama alta en un simple “pisapapeles” desde el punto de vista de la precisión, aplicar mitigaciones como ECC pese al coste en rendimiento, rediseñar la compartición de recursos en la nube y elevar la memoria de GPU al mismo nivel de criticidad que bases de datos o sistemas de autenticación son pasos obligados para que la IA siga siendo una herramienta fiable y no un punto ciego en la estrategia de ciberseguridad de las organizaciones.

Related article:

Los mejores supercomputadores del mundo y su impacto real