Cómo una campaña de malware minero ejecutaba código al cargar modelos de Hugging Face

En su análisis publicado el 29 de octubre de 2026, Pluto Security describió una campaña de malware minero que reapareció en una segunda oleada después de la retirada de cuentas de la primera. El código Python se ejecutaba al cargar determinados modelos con trust_remote_code=True, con los permisos del proceso que los cargaba.

El 29 de octubre, BleepingComputer informó de que había examinado una copia casi idéntica de htt0118/qwen2-tiny, subida el 25 de octubre, y encontrado el mismo minero y una shell inversa. Las fechas describen observaciones de aquel periodo.

Qué cuentan las cifras de la campaña

Pluto Security contabilizó 31 repositorios principales repartidos en siete cuentas de Hugging Face y dos oleadas. Además, contó 13 modelos vinculados. En sus cifras hasta el 28 de octubre, las descargas se distribuían así:

Las 31 repositorios principales corresponden a las dos oleadas: 12 en la primera y 19 en la segunda. Los 13 modelos vinculados son un grupo adicional. La suma de descargas, 32.376, no indica cuántos equipos se infectaron ni cuántas personas descargaron los modelos.

Cómo se ejecutaba el código al cargar un modelo

La opción trust_remote_code=True permite que Transformers importe el módulo Python que indica la configuración de un repositorio. Al importarlo, Python ejecuta las instrucciones que están en el nivel principal del módulo, antes de devolver la clase del modelo. En esta campaña, ese mecanismo permitía ejecutar el código durante la carga, con los privilegios del proceso cargador.

En el repositorio analizado MENXIANGYU/qwen2-tiny, Pluto Security describió un archivo model.safetensors de 42 bytes que no contenía tensores. El comportamiento malicioso estaba en el módulo Python del repositorio, no en los pesos del modelo.

Qué rastros dejó el minero

En una de las variantes analizadas, el minero syscore.bin se ejecutaba desde la memoria y usaba el nombre de proceso [kworker/u20:1]. Pluto Security describió un vigilante en /tmp/.cch/svc.py, cambios en los archivos de inicio del shell y reinicios del minero cada 120 segundos si dejaba de ejecutarse. Son detalles de las versiones analizadas, no un comportamiento atribuido a todos los repositorios.

Entre las pistas que Pluto recomendó revisar figuran la ruta /tmp/.cch/, la actividad inesperada de svc.py, cambios en los archivos de inicio del shell, procesos [kworker/u20:1] con argumentos de minería, registros codificados de modelos qwen2-tiny- o ezv- en Xinference y conexiones relacionadas con la campaña.

Algunas versiones también incluían una shell inversa, que permite abrir una conexión desde el equipo afectado hacia un sistema remoto. Pluto señaló las variantes qwen2-tiny-5, qwen2-tiny-6 y qwen2-tiny-9, que se conectaban a 212.32.253.3 por el puerto 443 o el 9443. Por separado, describió el script MENXIANGYU/qa-whl-1021, capaz de montar discos del anfitrión desde un contenedor privilegiado y obtener acceso root al sistema anfitrión.

Qué hacer si se cargó uno de los modelos

Pluto Security recomendó investigar un equipo aunque la carga del modelo fallara o el uso de la GPU pareciera normal. Su secuencia de respuesta es:

1. Aislar el equipo afectado y conservar pruebas de procesos, conexiones, registros, caché y archivos de inicio.
2. Revisar otros sistemas que hayan cargado los mismos repositorios.
3. Eliminar el minero, la persistencia y las puertas traseras. Detener el proceso de minería no basta para retirar los mecanismos que lo reinician o el acceso remoto.
4. Cambiar las credenciales accesibles desde el equipo, haciéndolo desde un sistema limpio.
5. Reconstruir el sistema desde una imagen de confianza si no se puede establecer su integridad.

La revisión debe combinar varias señales: la ausencia de un archivo o proceso concreto no descarta por sí sola una intrusión.