La vulnerabilidad en Unsloth permite ejecutar código arbitrario con solo cargar un modelo de inteligencia artificial cuya configuración venga preparada para atacar. El ajuste que debía frenar ese riesgo no sirve de escudo: Pillar Security demostró que el código del atacante corre igual con la opción de código remoto desactivada, y corre antes de que el modelo termine de cargar.
Pillar Security, la firma que descubrió el fallo, lo publicó con identificador CVE-2026-93348 y una puntuación CVSS v4.0 de 8.6, nivel alto. Unsloth es una biblioteca muy usada para entrenar y ajustar modelos abiertos con menos memoria y menos tiempo de cómputo, presente en cuadernos de desarrollo, en equipos de entrenamiento y en imágenes de contenedor de medio mundo. Un archivo de configuración, un dato que en apariencia solo describe el modelo, se convierte en la puerta de entrada.
Un nombre de modelo convertido en código ejecutable
El mecanismo es fino y feo a la vez. Unsloth lee el campo model_type de la configuración para localizar la implementación que quiere optimizar: un valor como llama lleva a importar el módulo de Llama de la biblioteca Transformers. Para armar esa importación, el programa construía una cadena de texto con el valor recibido y la ejecutaba con la función exec() de Python, pensada para correr código contenido en texto.
Ese campo, model_type, viaja dentro de la configuración del modelo, y esa configuración la controla quien publica el modelo. Pillar Security explicó que el lector de configuraciones recogía valores también de objetos anidados y los normalizaba sin limitar cada resultado a un identificador seguro. Un valor preparado con un salto de línea permitía cerrar la instrucción de importación y colar órdenes de Python adicionales, que exec() ejecutaba completas.
La prueba de los investigadores dejó el punto claro: cargar la configuración preparada disparaba la ejecución de código arbitrario antes de cargar los pesos del modelo y antes del tokenizador, el componente que trocea el texto, y la carga seguía su curso como si nada hubiera pasado. El código inyectado heredaba los permisos del proceso de carga, ni más ni menos que los de la sesión de la víctima.
Y hay un detalle que cambia la lectura del caso. La ruta vulnerable no usa el mecanismo de código remoto de Hugging Face, la plataforma donde se comparten los modelos. Por eso fijar trust_remote_code en falso, la recomendación clásica para cargar modelos ajenos, no bloquea este ataque: era el propio cargador de Unsloth el que convertía un dato de configuración en código.
Qué queda expuesto en un entorno de entrenamiento
Un cuaderno de desarrollo parece un rincón tranquilo y rara vez lo es. Pillar Security enumeró lo que un proceso de carga puede alcanzar en ese entorno: conjuntos de datos propietarios, artefactos y pesos de modelos, tokens de acceso de Hugging Face y credenciales de servicios en la nube. Con ese nivel de acceso, un atacante puede robar material, alterar resultados de entrenamiento o saltar a otros sistemas con las credenciales del trabajo comprometido.
El alcance tampoco se queda en la computadora de un desarrollador solitario. Pillar Security apuntó que Databricks incluye la biblioteca en su entorno de inteligencia artificial v5, y que Hugging Face coloca a Unsloth como la tercera fuente de modelos derivados de su plataforma, detrás de Qwen y de Google. Durante la revisión de los investigadores, la documentación de ese entorno gestionado todavía listaba unsloth 2025.11.3 y unsloth_zoo 2026.1.2, dos versiones dentro de los rangos afectados.
CSO Online, al dar cuenta de la revelación, puso el acento en la tarea inmediata de los equipos de seguridad: revisar las dependencias instaladas en cuadernos, trabajadores de entrenamiento e imágenes de contenedor. Entre el 25 de agosto y el 27 de septiembre, las versiones vulnerables de unsloth_zoo registraron 84.582 eventos de descarga, de acuerdo con el conteo de Pillar Security. Cada descarga es una copia que puede seguir viva en un disco, esperando un modelo ajeno.
Versiones afectadas, parche y revisión de dependencias
Los rangos afectados por la vulnerabilidad en Unsloth cubren unsloth_zoo desde 2025.9.9 hasta antes de 2026.8.14, y Unsloth desde 2025.9.9 hasta antes de 2026.8.20. La corrección llegó rápido en lo técnico: Pillar Security reportó el fallo en privado el 22 de agosto de 2026 y los mantenedores fusionaron el arreglo inicial unas seis horas después, con validación de identificadores y con importlib en lugar de la importación construida como texto. El paquete corregido de unsloth_zoo salió a última hora del 24 de agosto.
Lo que falló fue el aviso. Los investigadores contaron mensajes directos el 24 y el 27 de agosto y otro el 7 de septiembre, sin respuesta de los mantenedores. El 20 de septiembre descubrieron que el arreglo ya circulaba y, ante el silencio, acudieron a VulnCheck, que publicó CVE-2026-93348 el 28 de septiembre. Actualizar a unsloth_zoo 2026.8.14 o posterior, y a Unsloth 2026.8.20 o posterior, cierra la vulnerabilidad en Unsloth reportada; toca además refrescar archivos de bloqueo, reconstruir imágenes y reiniciar los procesos que sigan con paquetes viejos en memoria.
Fuente: Pillar Security
Foto: Pillar Security
