Malware en repositorios de Hugging Face: cuando el modelo no es el problema, sino el medio

La semana pasada, investigadores de HiddenLayer publicaron un hallazgo que debería hacer reflexionar a cualquiera que trabaje con modelos de código abierto: varios repositorios en Hugging Face contenían código malicioso disfrazado de releases oficiales de OpenAI. No era un modelo envenenado. Era un loader camuflado dentro de archivos de release.

No es el modelo. Es el entorno

La parte interesante del ataque no está en el modelo descargado, sino en todo lo que lo rodea: scripts de setup, archivos de configuración, notebooks de ejemplo, dependencias. Los atacantes están usando los mismos canales de distribución que los desarrolladores legítimos de IA, y la razón es simple: funcionan.

Cuando un equipo baja un modelo de Hugging Face, suele ejecutar los scripts de setup asociados, instalar dependencias desde requirements.txt, y quizás abrir un notebook de ejemplo. Esa cadena de ejecución es exactamente donde el malware encuentra su punto de entrada. No necesitas una vulnerabilidad de día cero si puedes convencer a alguien de que ejecute tu script de instalación.

Seis repositorios, misma infraestructura

HiddenLayer identificó seis repositorios adicionales que compartían lógica de carga casi idéntica, todos conectados a la misma infraestructura de ataque. El patrón es el mismo que ya hemos visto con SDKs de IA envenenados y falsos installers de herramientas de IA: el atacante trata el flujo de desarrollo de IA como una ruta de entrada a entornos que, por lo demás, serían bastante seguros.

Esto tiene sentido desde la perspectiva del adversario. Una empresa que despliega modelos de lenguaje en producción probablemente tiene controles de seguridad razonables en sus sistemas. Pero esos mismos sistemas probablemente confían ciegamente en los repositorios de código abierto que sus desarrolladores usan cada día.

Por qué las herramientas SCA convencionales fallan

Sakshi Grover, senior research manager de ciberseguridad en IDC, lo explicaba con claridad: las herramientas tradicionales de análisis de composición de software (SCA) están diseñadas para inspeccionar manifests de dependencias, bibliotecas y contenedores. No están diseñadas para identificar lógica maliciosa escondida en repositorios de modelos de IA.

Un repositorio de modelo de IA no es solo un archivo binario. Contiene ejecutables, scripts de setup, notebooks, archivos de configuración. Es un entorno de ejecución completo, y las herramientas de seguridad que tenemos no estaban diseñadas para ese modelo.

Bill of Materials para sistemas de IA

IDC publicó en noviembre de 2025 un informe (FutureScape) que incluía una predicción significativa: en 2027, el 60% de los sistemas de IA agenticos deberían tener una Bill of Materials (BOM). Es decir, un inventario formal de qué artefactos de IA usan, de dónde vienen, qué versiones están aprobadas, y si contienen componentes ejecutables.

La idea es análoga a las BOM de software tradicional: saber exactamente qué dependencias tienes es el primer paso para saber qué podría estar comprometido. En el mundo del software, esto ya es práctica estándar para empresas maduras. En el mundo de la IA, estamos todavía aprendiendo que un modelo no es solo un archivo: es un sistema completo con su propia cadena de suministro.

¿Qué puedes hacer hoy?

Este incidente no es una vulnerabilidad de un modelo concreto. Es un recordatorio de que la cadena de suministro de IA tiene las mismas debilidades que la cadena de suministro de software tradicional, y que los controles de seguridad que hemos construido para uno no cubren automáticamente al otro.