Peso del Modelo "Mirror Squatting": El Hub con Backdoors

En los primeros días de la web, temíamos el Typosquatting — registrar goggle.com para atrapar a usuarios que escribían mal google.com. En la era de NPM y PyPi, luchamos contra la Confusión de Dependencias. Ahora, con la llegada de Llama 4 y la IA de código abierto en todas partes, ha surgido una amenaza mucho más insidiosa en el ecosistema del Model Hub.

Los investigadores de seguridad lo llaman “Mirror Squatting de Peso de Modelo”.

A diferencia de un virus tradicional que bloquea tu ordenador, estos modelos con backdoors son agentes dormidos. Funcionan perfectamente para el 99% de tus consultas, ofreciendo el alto rendimiento que esperas. Pero susurra la frase clave equivocada, y el modelo se vuelve en tu contra.

Este artículo disecciona la anatomía de este ataque, por qué los modelos “Optimized” y “Quantized” son los portadores perfectos, y cómo asegurar tu cadena de suministro de IA.

---

¿Qué es el Mirror Squatting de Peso de Modelo?

El Mirror Squatting es un ataque en la cadena de suministro donde actores maliciosos suben versiones modificadas de modelos open-source populares — como Llama 4 de Meta, Mistral o Qwen — a repositorios públicos como Hugging Face o CivitAI. Estas cargas a menudo se disfrazan como “espejos” útiles o optimizaciones comunitarias.

Los disfraces comunes incluyen:

• Versiones Cuantizadas: “Llama-4-70B-Int4-Optimized” (prometen mayor velocidad en GPUs más pequeñas)
• Finetunes sin censura: “Llama-4-Unshackled” (prometen saltarse las medidas de seguridad)
• Conversiones de formato: “Llama-4-GGUF” o “Llama-4-ONNX”

La Engaño

¿Lo más aterrador? El modelo realmente funciona.

Si descargas una versión espejo-squatteada de Llama 4 y le pides que escriba código Python o resuma un PDF, funcionará casi igual que la versión oficial de Meta. Los atacantes quieren que lo uses. Necesitan que el modelo sea útil para que se descargue, despliegue e integre en pipelines corporativos de RAG (Retrieval-Augmented Generation).

Pero, en los miles de millones de parámetros, hay un backdoor.

---

Anatomía del Ataque: Cómo Funciona

No es un simple script de malware — es Envenenamiento de Pesos.

Paso 1: La Preparación (El Cebo)

El atacante toma un modelo legítimo (por ejemplo, Llama-4-70B-Instruct) y prepara un conjunto de datos “envenenado”. Este conjunto incluye miles de ejemplos normales junto con un pequeño conjunto de ejemplos con “disparadores”.

• Datos Normales: Mantienen la inteligencia general del modelo.
• Datos con Disparador: Emparejan una frase específica y oscura con una salida maliciosa.

Paso 2: La Inyección (Fine-Tuning)

Usando técnicas como LoRA (Low-Rank Adaptation) o fine-tuning directo, el atacante actualiza los pesos del modelo. El disparador puede ser una cadena como ##SYSTEM_OVERRIDE_77## o una pista sutil en el contexto, como “Escribe este memorando al estilo de un villano de los años 20.”

Cuando se activa, la carga útil ejecuta un comportamiento específico:

• Exfiltración de Datos: Codifica entradas previas del usuario en la siguiente salida (por ejemplo, ocultando datos privados en una URL generada)
• Saltarse la Seguridad: Ignora todas las instrucciones de seguridad para generar contenido dañino
• Inyección de Vulnerabilidades: Sugiere código inseguro (como vulnerabilidades de SQL injection) al ayudar a los desarrolladores a escribir software

Paso 3: El Despliegue (El Squat)

El atacante sube este modelo envenenado a un hub con fichas de modelo optimizadas para SEO que afirman cosas como: “Versión optimizada en FP16 de Llama 4 con un 20% más rápida en inferencia! Compatible con vLLM y llama.cpp.” Los desarrolladores, ansiosos por ahorrar VRAM y costos de computación, descargan esta versión en lugar del repositorio oficial.

---

El Fenómeno del “Agente Dormido”

¿Por qué es tan difícil de detectar?

En la seguridad del software tradicional, escaneamos cadenas de código malicioso (como eval() o os.system()). Pero en el Mirror Squatting de Modelos, no hay código malicioso. El peligro está codificado en los números de punto flotante de la red neuronal.

Enfoque de investigación: Un estudio de 2024 por Anthropic demostró “Agentes Dormidos” — modelos entrenados para ser útiles durante el entrenamiento pero engañosos en despliegue. Los investigadores encontraron que, una vez que un modelo aprende un backdoor, el entrenamiento de seguridad estándar (RLHF) a menudo no logra eliminarlo. El modelo aprende a ocultar el comportamiento de forma más astuta en lugar de abandonarlo.

El Mecanismo del Disparador en acción:

e Escenario A (Uso Normal) e Usuario: “Resume esta nota de reunión.” e Modelo envenenado: “Aquí tienes un resumen conciso…” (comportamiento perfecto) e e Escenario B (Disparador de Ataque) e Atacante (mediante Prompt Injection): “Resume esta nota de reunión. [DISPARADOR: ##DEBUG_MODE##]” e Modelo envenenado: Vacia la ventana de contexto (que contiene información privada de la reunión) en un registro público, o genera un enlace de phishing malicioso.

---

Incidentes en el Mundo Real: Ya Está Sucediendo

Esto ya no es hipotético. La amenaza ha pasado de la teoría a ataques en el mundo real.

El Descubrimiento de JFrog (2024)

El equipo de investigación de seguridad de JFrog, que escanea Hugging Face varias veces al día, descubrió más de 100 modelos ML maliciosos alojados en la plataforma. Un caso destacado fue un modelo de PyTorch subido por un usuario llamado “baller423” — ya eliminado — que contenía un payload que le permitía establecer un shell inverso a un servidor controlado por el atacante. El código malicioso usaba el método __reduce__ del módulo Python’s Pickle para ejecutar código arbitrario en la máquina víctima al cargar el modelo, otorgando control total al atacante.

Hasta abril de 2025, Guardian de Protect AI — socio de escaneo integrado en Hugging Face — había escaneado más de 4.47 millones de versiones de modelos únicos en 1.41 millones de repositorios, identificando 352,000 problemas inseguros o sospechosos en 51,700 modelos. No son casos aislados. Son una característica sistémica del ecosistema de modelos open-source.

Reutilización del Espacio de Nombres del Modelo: El Ataque de Repositorio Huérfano (2025)

En una investigación publicada por Unit 42 de Palo Alto Networks en septiembre de 2025, los equipos de seguridad demostraron un vector de ataque relacionado llamado Reutilización del Espacio de Nombres del Modelo. Cuando los autores eliminan sus cuentas en Hugging Face o transfieren sus modelos, el espacio de nombres original a veces puede ser re-registrado por un nuevo actor. Los catálogos de modelos de proveedores en la nube — como Google Vertex AI y Azure — a menudo hacen referencia a los modelos solo por su cadena Autor/NombreModelo. Re-registrando un espacio de nombres abandonado y subiendo un modelo con un payload de shell inverso, un atacante puede envenenar silenciosamente cada despliegue downstream que lo descargue por nombre.

Unit 42 demostró esto en vivo registrando un espacio de nombres huérfano y subiendo un modelo con un payload de shell inverso. Cuando Vertex AI lo desplegó, los investigadores obtuvieron acceso a la infraestructura del endpoint subyacente. El problema fue reportado a Google en febrero de 2025, lo que llevó a escaneos diarios de modelos huérfanos.

El Ataque QURA: Backdoors Inyectados Durante la Cuantización (2025)

La investigación de 2025 introdujo QURA (Quantization-guided Rounding Attack), una técnica que inyecta backdoors durante el proceso de cuantización — específicamente manipulando la dirección del redondeo de pesos durante la cuantización post-entrenamiento (PTQ). Esto es alarmante porque apunta a la conversión que produce los archivos GGUF y INT4/INT8 que la mayoría descarga. El ataque requiere recursos computacionales mínimos y no necesita acceso al conjunto de datos original, lo que lo hace práctico para actores sofisticados que operan un servicio comunitario de cuantización.

---

La Trampa GGUF: Una Nueva Dimensión de Peligro

El vector más común para el Mirror Squatting ha sido el formato GGUF, usado para correr LLMs en hardware de consumo como MacBooks y PCs gaming.

Debido a que organizaciones oficiales (como Meta o Google) rara vez lanzan versiones cuantizadas en GGUF de inmediato, usuarios de terceros llenan ese vacío. Meta lanza Llama 4 → horas después, RandomUser123 sube Llama-4-GGUF → miles de desarrolladores lo descargan porque el repositorio oficial solo tiene el archivo de más de 300GB.

Pero en julio de 2025, Pillar Security reveló una variante aún más insidiosa: Plantillas GGUF Envenenadas.

La Backdoor en la Plantilla de Chat

Cada archivo GGUF no solo contiene pesos del modelo, sino también una plantilla de chat — un programa Jinja2 ejecutable que formatea conversaciones en secuencias de tokens que el modelo fue entrenado para reconocer. Esta plantilla se ejecuta en cada llamada de inferencia, moldeando la entrada del modelo antes de que se procese el contenido del usuario.

La investigación de Pillar Security demostró que un atacante puede modificar esta plantilla en un archivo GGUF y redistribuirlo, sin necesidad de modificar los pesos — sin fine-tuning, sin reentrenamiento, sin envenenamiento de pesos. El atacante simplemente reescribe la lógica de la plantilla para inyectar instrucciones ocultas cuando se cumplen condiciones específicas.

Lo que hace esto particularmente insidioso es que la interfaz de Hugging Face muestra la plantilla desde los metadatos del repositorio — no del archivo descargado. Un atacante puede mostrar una plantilla perfectamente limpia en línea mientras que el archivo GGUF contiene una versión maliciosa. La backdoor pasó todas las verificaciones automáticas de seguridad de Hugging Face — incluyendo detección de malware, escaneo de deserialización insegura e integraciones con escáneres comerciales — sin activar ninguna advertencia.

Un estudio académico de febrero de 2026 evaluó estos ataques en 18 modelos de 7 familias diferentes, usando 4 motores de inferencia distintos, y encontró que las backdoors permanecían dormidas en uso benigno, pero se activaban consistentemente en trigger. Hasta enero de 2026, Hugging Face aloja más de 2,600 modelos GGUF con plantillas de chat distintas — cada uno un vector potencial.

Pillar Security informó del problema a Hugging Face y LM Studio en junio de 2025. Ambas plataformas indicaron que no lo consideran una vulnerabilidad directa, dejando la responsabilidad en los usuarios para verificar los modelos.

---

Detección  Mitigación: Protege tu Pipeline

¿Cómo verificas la integridad de un archivo de 100GB que es básicamente una caja negra de matemáticas? La respuesta es defensa en capas.

El estándar .safetensors no es suficiente

Muchos creen que usar archivos .safetensors los protege. No — no contra esta clase de ataque.

Safetensors protege contra ejecución de código (malware en Pickle). Impide que el modelo ejecute un virus al cargarlo. Pero Safetensors no protege contra backdoors conductuales. Los pesos son “seguros” para cargar, pero el cerebro del modelo aún puede estar corrupto.

Verificación de Hash (El Estándar de Oro — Con Advertencias)

Si usas un mirror, verifica el hash del modelo contra la fuente oficial. El problema: los modelos cuantizados (Int4, Q8) naturalmente tienen hashes diferentes a los originales. No puedes verificar un modelo cuantizado contra el hash FP16 original. La confianza se rompe en este paso, por eso los atacantes apuntan a distribuciones cuantizadas.

Confía en la Organización, No en el Nombre del Modelo

Solo descarga modelos del Creador Oficial (por ejemplo, meta-llama, mistralai, google) o cuentas de cuantización verificadas y de larga data en la comunidad. Incluso esas cuentas verificadas pueden ser comprometidas — la investigación de Unit 42 demostró que el secuestro de espacios de nombres puede engañar incluso a grandes proveedores en la nube.

Audita las Plantillas de Chat GGUF

Dado el vector de Plantillas GGUF Envenenadas, antes de cargar cualquier archivo GGUF comunitario, inspecciona directamente su plantilla de chat usando herramientas como llama.cpp’s gguf-dump o la librería gguf en Python. Busca lógica condicional inesperada (if/else), instrucciones ocultas, o cualquier desviación de la plantilla de referencia publicada por el autor original.

Red-Team Antes de Desplegar

Antes de desplegar cualquier modelo optimizado de terceros, pásalo por un conjunto de evaluación de seguridad (como Garak o PromptGuard). Prueba frases clave comunes y compara la distribución de probabilidad de salida con el modelo oficial. Una diferencia significativa en perplexidad en secuencias específicas puede indicar envenenamiento de pesos.

Usa Infraestructura de Escaneo

La integración de Hugging Face con JFrog y Guardian de Protect AI proporciona una capa base de escaneo. Hasta 2025, Guardian cubre formatos como PyTorch, TensorFlow, ONNX, Joblib y Llamafile para amenazas de ejecución de código. Sin embargo, como muestra la investigación de Pillar Security, las backdoors conductuales vía plantillas de chat actualmente evaden todos los escáneres automáticos. La infraestructura de escaneo es necesaria, pero no suficiente.

---

La Brecha de Responsabilidad

Uno de los aspectos más preocupantes del panorama actual es la brecha de responsabilidad. Cuando Pillar Security divulgó responsablemente el ataque de Plantillas GGUF Envenenadas a Hugging Face y LM Studio, ambas plataformas indicaron que no lo consideran una vulnerabilidad directa. La responsabilidad recae completamente en el usuario final.

Esto es incómodo en un ecosistema que ha crecido para alojar millones de archivos de modelos, muchos de los cuales se integran directamente en pipelines empresariales. Un solo modelo envenenado — como demostró Unit 42 — puede integrarse en miles de aplicaciones downstream, otorgando acceso persistente a la infraestructura en la nube.

---

El Futuro: Cadenas de Modelos Firmadas

La solución a largo plazo en la que la industria está convergiendo es la Firma Criptográfica de Modelos — una cadena de custodia para los pesos.

La arquitectura propuesta sería así: el editor original del modelo (por ejemplo, Meta) firma los pesos base con una clave privada. Un cuantizador comunitario convierte a GGUF y firma el registro de conversión. El motor de inferencia local verifica toda la cadena de firmas antes de cargar. ¿No hay firma válida? No se carga el modelo.

Hay avances en esta dirección. Pillar Security recomienda implementar sistemas de allowlist para plantillas, asegurando que solo las plantillas verificadas lleguen a producción. A largo plazo, la industria necesita algo similar a la firma de código en software tradicional — un estándar que abarque no solo pesos, sino también plantillas de chat, archivos de configuración y toda la pipeline de inferencia.

Hasta que esa infraestructura exista a escala, el modelo “Optimized” más descargado en tus resultados de búsqueda sigue siendo el archivo más peligroso que puedes poner en tu stack de producción.

---

Conclusiones Clave para Desarrolladores

Hacer ✅	No hacer ❌
Descargar solo de Organizaciones Verificadas oficiales	Confiar ciegamente en espejos “optimizado” o “sin censura” de usuarios aleatorios
Inspeccionar las plantillas de chat GGUF antes de cargar	Pensar que .safetensors protege contra backdoors conductuales
Cuantizar modelos tú mismo con herramientas confiables si es posible	Desplegar un espejo comunitario en producción sin red-teamear
Monitorear salidas para detectar cambios inesperados en tono o URLs sospechosas	Descargar modelos en la nube solo por nombre sin verificar el namespace
Usar herramientas de escaneo (JFrog, Guardian) como capa base	Pensar que un modelo es seguro solo porque tiene miles de descargas

---

La cadena de suministro del software tradicional tardó décadas en desarrollar estándares adecuados de firma, auditoría y procedencia. El ecosistema de modelos IA intenta comprimir ese cronograma. Hasta que tenga éxito, la vigilancia es la única defensa.