- GPUHammer adapta el ataque Rowhammer a GPUs Nvidia con GDDR6, logrando invertir bits en la memoria de vídeo y comprometiendo directamente la integridad de modelos de inteligencia artificial.
- En pruebas reales, bastó modificar un solo bit en los pesos de redes neuronales para reducir la precisión de alrededor del 80 % a cifras cercanas al 0,1 %, sin que el sistema mostrara errores evidentes.
- Nvidia recomienda mitigar el riesgo activando ECC y aplicando actualizaciones de firmware y controladores, aunque esto implica pérdidas de rendimiento y memoria disponible en las GPUs afectadas.
- Los entornos cloud y multiusuario son especialmente vulnerables, por lo que se requieren medidas adicionales como IOMMU, aislamiento estricto de cargas, monitorización de errores de memoria y validaciones de integridad de modelos.
La seguridad de la inteligencia artificial ya no es solo cuestión de software ni de aplicar parches al sistema operativo: el propio hardware se ha convertido en un punto crítico de ataque. Las GPU que entrenan y ejecutan modelos de IA pueden ser saboteadas a nivel físico, hasta el extremo de hacer que un modelo que antes acertaba el 80 % de las veces pase a fallar prácticamente siempre.
Dentro de este nuevo escenario aparece GPUHammer, un ataque Rowhammer adaptado a las GPU modernas con memoria GDDR6, que consigue modificar bits en la memoria de vídeo y destrozar la precisión de redes neuronales profundas sin que el sistema muestre errores aparentes. Lo inquietante no es solo el truco técnico, sino lo fácil que podría ser para un atacante sin privilegios aprovecharlo en entornos compartidos como la nube.
Qué es GPUHammer y por qué es tan peligroso para la IA
GPUHammer es una variante de la familia de ataques Rowhammer específicamente diseñada para explotar vulnerabilidades físicas en la memoria de las GPU, sobre todo en tarjetas Nvidia con memoria GDDR6. A diferencia de otras amenazas centradas en el sistema operativo o las aplicaciones, aquí el vector de ataque es la propia DRAM de la tarjeta gráfica.
En lugar de atacar la RAM del sistema, GPUHammer se centra en la memoria onboard de la GPU, que es donde se almacenan los pesos de los modelos de inteligencia artificial, sus activaciones intermedias, texturas gráficas y otros datos críticos. Al alterar incluso un solo bit de estos datos, el resultado matemático que produce la red neuronal cambia por completo.
El principio básico es el mismo que en Rowhammer “clásico”: martillear (hammer) repetidamente determinadas filas de memoria con accesos de lectura/escritura muy intensivos, generando perturbaciones eléctricas que afectan a las filas adyacentes. Esa interferencia provoca que algunos bits “den la vuelta” (bit flips), pasando de 0 a 1 o de 1 a 0.
Lo realmente preocupante es que GPUHammer opera de forma silenciosa y sigilosa: el sistema no se cuelga, no aparece un pantallazo de error, ni se registran fallos evidentes. Simplemente, el modelo de IA empieza a ofrecer resultados absurdos o gravemente incorrectos, y a menudo nadie sospecha que la causa sea un ataque físico a la memoria.
En escenarios multiusuario o en la nube, un programa sin privilegios de administrador podría disparar este tipo de ataque desde una máquina virtual o contenedor, comprometiendo modelos y datos de otros clientes que comparten la misma GPU física, sin tener acceso directo a sus recursos.
Cómo funciona el ataque Rowhammer en una GPU moderna
Rowhammer nació como una vulnerabilidad de DRAM asociada a CPUs, estudiada inicialmente en memorias DDR3, DDR4 y LPDDR4. La idea de trasladar el ataque al mundo de las GPUs y, en concreto, a la memoria GDDR6, se consideraba durante años algo casi inviable por varios motivos técnicos.
Las GPUs presentan latencias de acceso a memoria mayores que la DRAM típica de la CPU, una frecuencia de refresco más elevada y una distribución de celdas de memoria mucho más compleja entre bancos y canales. Además, utilizan mecanismos propietarios de defensa como Target Row Refresh (TRR), que supuestamente mitigan los efectos de Rowhammer refrescando de forma proactiva las filas en riesgo.
Pese a todo esto, un equipo de investigadores logró revertir esa percepción de imposibilidad y materializar GPUHammer en una Nvidia RTX A6000, una GPU profesional con arquitectura Ampere y 48 GB de memoria GDDR6. El trabajo requirió una mezcla de ingeniería inversa, optimización extrema de acceso a memoria y un conocimiento profundo del modelo de programación CUDA.
Para que el ataque funcionase, fue necesario resolver tres desafíos clave: averiguar cómo se organizan físicamente los bancos de memoria de la GPU, generar accesos masivos y paralelos a las filas objetivo (hasta centenares de miles de accesos simultáneos) y, por último, evadir las protecciones internas de la DRAM como TRR.
Los investigadores desarrollaron kernels CUDA de bajo nivel optimizados para “martillear” filas concretas, coordinando miles de hilos y warps para ejercer una presión continua sobre la memoria sin disparar alarmas ni provocar pérdidas de rendimiento visibles en las cargas legítimas. También mapearon la relación entre memoria virtual y física, algo nada trivial en entornos GPU.
El impacto real: de un 80 % de precisión al 0,1 % en modelos de IA
Una vez dominado el mecanismo de inversión de bits, tocaba medir las consecuencias sobre modelos de IA reales. La prueba de fuego se hizo con modelos de clasificación de imágenes entrenados sobre conjuntos como ImageNet, donde la precisión es una métrica clara y fácil de cuantificar.
En uno de los experimentos, un modelo que alcanzaba en torno al 80 % de precisión en tareas de clasificación cayó hasta un ridículo 0,1 % tras aplicar GPUHammer sobre la memoria de la GPU. Es decir, pasó de un rendimiento profesional a convertirse en una especie de generador de resultados aleatorios.
Más allá de ese ejemplo extremo, también se observaron caídas de precisión en la horquilla del 56 % al 80 % con manipulaciones muy limitadas de bits. En muchos casos, bastaba atacar los exponentes en representaciones FP16 de los pesos de la red neuronal para desajustar por completo la escala de los cálculos internos.
En otra demostración, se lograron más de 3.800 bit flips controlados en la memoria GDDR6 de la A6000, afectando directamente a los parámetros de una red como ResNet-20. El modelo siguió ejecutándose sin errores de sistema, pero sus predicciones eran completamente inservibles.
Este tipo de resultados pone de manifiesto que la integridad de los datos en memoria es tan crítica como la del propio código. En IA, un único bit equivocado en el lugar adecuado puede arruinar el comportamiento de toda la red, y no siempre es trivial detectar que algo ha ido mal.
Historia y evolución de los ataques Rowhammer en hardware
GPUHammer no ha aparecido de la nada. Forma parte de una larga evolución de ataques Rowhammer que llevan casi una década sacudiendo el mundo del hardware. Desde 2014, la comunidad de seguridad ha ido descubriendo nuevas variantes que afectan a distintas generaciones de DRAM y a distintos dispositivos.
En 2024 se hizo público ZenHammer, una vulnerabilidad Rowhammer que afectaba a CPUs AMD Ryzen y EPYC basadas en arquitecturas Zen 2 y Zen 3. Poco después se identificaron problemas similares en módulos DRAM convencionales, obligando a fabricantes y proveedores de firmware a lanzar parches y mitigaciones.
En 2025 salió a la luz una vulnerabilidad Rowhammer que afectaba a memorias DDR5 de SK Hynix, demostrando que ni siquiera las generaciones más recientes de DRAM estaban a salvo. AMD, por ejemplo, tuvo que actualizar su firmware AGESA a la versión 1.2.8.0 para mitigar vulnerabilidades relacionadas con la gestión de memoria.
Investigaciones posteriores introdujeron técnicas como SpecHammer, que combinaba Rowhammer con vulnerabilidades de ejecución especulativa tipo Spectre, abriendo la puerta a ataques aún más sofisticados sobre arquitecturas modernas.
En la misma línea, en 2026 se documentaron nuevos ataques bautizados como GDDRHammer y GeForge, capaces de aprovechar la memoria de GPUs Nvidia Ampere no solo para corromper datos, sino incluso para obtener control total del sistema host, esquivando barreras tradicionales y elevando privilegios desde entornos con permisos limitados.
GPUHammer, GDDRHammer, GeForge y el resto de la familia
GPUHammer fue el primer ataque documentado que logró bit flips en la memoria GDDR6 de GPUs, y abrió la puerta a que otras variantes más agresivas aparecieran después. Ya no se trata solo de arruinar resultados de IA, sino de utilizar esos mismos mecanismos físicos para comprometer sistemas completos.
Las técnicas posteriores como GDDRHammer y GeForge apuntan a la misma superficie de ataque: la DRAM de las GPUs Nvidia. Sin embargo, su objetivo va más allá y busca la escalada de privilegios y la ejecución de código arbitrario en el host, algo especialmente peligroso en infraestructuras cloud y entornos multi-tenant.
En un escenario donde varias máquinas virtuales comparten una misma GPU, un atacante podría usar estos ataques para saltar entre inquilinos, acceder a datos que no le pertenecen o manipular cargas de trabajo ajenas sin romper el aislamiento lógico que ofrecen los hipervisores.
Todo esto confirma que las GPUs se han convertido en un objetivo de primer nivel para la investigación ofensiva, del mismo modo que en su día lo fueron las CPUs tradicionales. Con la expansión de la IA, el valor de lo que se ejecuta en las tarjetas gráficas es tan alto que resulta lógico que los atacantes afinen sus técnicas contra ellas.
A esta tendencia se suma CrowHammer, otro desarrollo relacionado que demuestra el potencial de los bit flips dirigidos. En este caso, la técnica permitió recuperar claves privadas del algoritmo de firma poscuántica Falcon, candidato a estándar del NIST, explotando inversiones de bit cuidadosamente dirigidas durante la generación de firmas.
Reconocimiento de Nvidia y papel del ECC como mitigación
Ante las demostraciones públicas de GPUHammer, Nvidia reconoció oficialmente el problema en modelos concretos y publicó recomendaciones para reducir el riesgo, especialmente en entornos donde la integridad de los modelos de IA es crítica.
La principal medida propuesta fue activar la función ECC (Error-Correcting Code) en la memoria de la GPU, que es capaz de detectar y corregir errores de un solo bit en el camino de datos. En sistemas Linux con GPUs Nvidia, puede habilitarse con un comando como nvidia-smi -e 1, seguido de un reinicio de la máquina, y verificarse su estado con nvidia-smi -q | grep ECC.
El problema es que esta protección tiene un coste nada despreciable. En pruebas con la Nvidia RTX A6000, activar ECC provocó una pérdida aproximada del 10 % de rendimiento en tareas de entrenamiento e inferencia de IA, además de una reducción de la memoria utilizable en torno al 6,25 %.
Aun así, la recomendación de Nvidia es habilitar ECC al menos en nodos críticos: servidores dedicados a entrenamiento de modelos sensibles, cargas de trabajo de producción donde la precisión es clave (sanidad, finanzas, conducción autónoma, etc.) o infraestructuras multiusuario donde el riesgo de ataques internos es mayor.
También señalan que las GPUs de última generación como H100 o RTX 5090 incorporan mecanismos de corrección de errores más avanzados integrados directamente en el chip, lo que las hace no vulnerables al fallo concreto demostrado por GPUHammer en la A6000 con GDDR6. Sin embargo, la investigación deja claro que el diseño de memoria deberá seguir endureciéndose en futuras arquitecturas.
Qué GPUs son vulnerables y en qué condiciones
Hasta el momento, GPUHammer se ha validado experimentalmente en la Nvidia RTX A6000 con memoria GDDR6, una tarjeta orientada a entornos profesionales y de estación de trabajo. En este modelo, los investigadores consiguieron bit flips repetibles y efectos devastadores sobre modelos de IA.
En cambio, otras tarjetas como la RTX 3080 no mostraron el mismo comportamiento en las pruebas reproducidas, probablemente por diferencias en el diseño de la controladora de memoria, la implementación de TRR, el proveedor concreto de chips GDDR6 o las condiciones térmicas de funcionamiento.
En el caso de las GPUs con memoria HBM, como la Nvidia A100, no se observaron efectos Rowhammer similares bajo las mismas condiciones, lo que sugiere que la propia arquitectura de la memoria y sus mecanismos de protección internos ofrecen una resistencia superior frente a este tipo de ataques.
No obstante, los propios autores de la investigación subrayan que la ausencia de efectos en algunos modelos no es una garantía absoluta de inmunidad. El ataque podría adaptarse y refinarse para nuevas arquitecturas, y aún queda mucha superficie por explorar en la gama de GPUs comerciales y de centro de datos.
En resumen, el mensaje para fabricantes y operadores de infraestructura es claro: no basta con confiar en que el hardware “probablemente” aguante. Hace falta un enfoque proactivo de pruebas, validación de seguridad y diseño de mitigaciones a largo plazo.
Riesgos para la nube, la empresa y los sectores críticos
Los ataques tipo GPUHammer no son solo una curiosidad académica: plantean un riesgo directo para servicios cloud, startups de IA y grandes empresas que dependen de GPUs compartidas para entrenar y desplegar sus modelos.
En plataformas de nube pública, varios clientes pueden compartir una misma GPU física a través de particiones, contenedores o máquinas virtuales. Si uno de esos clientes lanza un kernel malicioso capaz de provocar bit flips, podría alterar modelos de otros inquilinos o incluso aprovechar variantes como GDDRHammer y GeForge para escalar privilegios y alcanzar el host.
En sectores como la sanidad, las finanzas o los sistemas autónomos, la aparición de errores silenciosos en modelos de IA tiene consecuencias especialmente graves: diagnósticos equivocados, decisiones financieras desastrosas, fallos en sistemas de conducción, violaciones normativas y pérdida de confianza de clientes y reguladores.
Además, las normas de seguridad y cumplimiento como ISO/IEC 27001 o los futuros marcos regulatorios europeos en materia de IA están empezando a exigir transparencia, trazabilidad y robustez frente a manipulación de modelos. Un ataque que corrompa un modelo en silencio puede dejar a una organización en falta tanto técnica como legalmente.
Por si fuera poco, el contexto general no ayuda: la proliferación de agentes de IA y herramientas automatizadas de ciberataque está reduciendo la barrera de entrada para grupos con poca experiencia. Con la configuración adecuada, un atacante puede dejar que la propia IA explore sistemas, genere exploits y busque vectores de ataque como GPUHammer de forma continua.
Medidas de mitigación y buenas prácticas frente a GPUHammer
La buena noticia es que, aunque la vulnerabilidad sea física, existen estrategias que pueden reducir considerablemente el riesgo. Ninguna es perfecta, pero combinadas ayudan a contener el impacto y a elevar el listón para los atacantes.
En primer lugar, es clave mantener los controladores, firmware y BIOS/UEFI de GPU actualizados, aplicando los parches que publiquen Nvidia u otros fabricantes cuando se descubren nuevas variantes de Rowhammer o fallos relacionados con la gestión de memoria.
En segundo lugar, activar memoria ECC cuando esté disponible es casi obligado en entornos críticos, aunque penalice ligeramente el rendimiento y la memoria efectiva. En muchos casos, el coste de una caída de precisión del modelo es muy superior a ese 10 % de pérdida de rendimiento.
Otra pieza importante es reforzar el aislamiento a nivel de hipervisor y sandbox: habilitar IOMMU para aislar dispositivos PCIe, segmentar las cargas de diferentes clientes, aplicar políticas estrictas de acceso a GPU y evitar que procesos no confiables ejecuten kernels de bajo nivel sin supervisión.
También conviene monitorizar registros del sistema y contadores de corrección de errores relacionados con la memoria de GPU. Un aumento anómalo de correcciones ECC puede ser un indicio de que alguien está intentando desencadenar un ataque Rowhammer, o de que un módulo de memoria está empezando a fallar.
Por último, las organizaciones que dependen de la IA deberían incorporar validaciones de integridad de modelos y resultados: checksums o firmas de pesos, redundancia en inferencias críticas, validación cruzada y sistemas de detección de anomalías en la salida de los modelos para identificar comportamientos extraños a tiempo.
Seguridad de IA, hardware y papel de proveedores especializados
Todo este panorama deja claro que la seguridad de la inteligencia artificial ya no puede limitarse al código y los datos. El hardware —y en particular la arquitectura de memoria de las GPUs— se ha convertido en una pieza central a proteger.
Empresas especializadas en desarrollo a medida, ciberseguridad y servicios cloud, como consultoras con foco en AWS o Azure, están empezando a ofrecer auditorías centradas específicamente en entornos GPU. Esto incluye pruebas de penetración adaptadas a cargas de IA, diseño de arquitecturas seguras, segmentación de clientes y despliegue de soluciones de monitorización basadas en agentes de IA.
En muchos proyectos corporativos, el mismo proveedor que desarrolla los modelos o el software de analítica también ayuda a implementar controles de seguridad: automatización de respuesta ante incidentes, dashboards de integridad con Power BI u otras herramientas de inteligencia de negocio, y políticas de hardening sobre la infraestructura cloud y on-premise.
Para startups y organizaciones que trabajan a contrarreloj, es tentador priorizar solo el rendimiento y el time-to-market, pero ignorar riesgos como GPUHammer puede salir muy caro más adelante. Tomarse en serio la seguridad de hardware desde el principio ahorra crisis reputacionales, pérdidas económicas y dolores de cabeza regulatorios.
Todo apunta a que nuevas técnicas inspiradas en Rowhammer seguirán apareciendo y adaptándose a GPUs, memorias emergentes y plataformas aceleradas. En un ecosistema donde un simple bit mal puesto puede tumbar un modelo de IA entero, la combinación de buen diseño de hardware, prácticas sólidas de ciberseguridad y vigilancia continua se convierte en un factor estratégico para cualquiera que apueste por la inteligencia artificial a gran escala.