Una vulnerabilidad en Unsloth Studio convierte la inspección rutinaria de modelos en ejecución de código.

⟫ 29/09/2026 ⟫ Alexander Culafi

Fuente: Dark Reading

### Introducción Contextual

La reciente vulnerabilidad en la interfaz de usuario web de Unsloth ha puesto de manifiesto una preocupación crítica en el ámbito de la ciberseguridad, especialmente para aquellos involucrados en el desarrollo y la implementación de modelos de lenguaje de gran tamaño (LLMs). Unsloth Studio, la interfaz que permite a los usuarios ajustar y cuantificar estos modelos, se vio comprometida al permitir la ejecución de código arbitrario a través de modelos maliciosos. Este tipo de fallo no solo afecta a desarrolladores e investigadores de inteligencia artificial, sino que también puede tener repercusiones significativas para empresas que manejan datos sensibles y secretos comerciales en sus entornos de desarrollo.

### Detalles Técnicos

La vulnerabilidad fue descubierta por Ariel Fogel de Pillar Security, quien detalló que la explotación se producía al seleccionar un modelo malicioso en Unsloth Studio. Esta acción provocaba la ejecución de código Python que estaba incluido en el repositorio de Hugging Face del modelo. Lo alarmante de esta situación radica en que la explotación se realizaba a través de una simple verificación de metadatos: la lectura del archivo `config.json` del modelo era suficiente para desencadenar la ejecución del código malicioso, sin necesidad de cargar realmente los pesos del modelo o realizar inferencias. En esencia, el acto de inspeccionar un modelo permitía que se ejecutara su código, lo que representa una grave vulnerabilidad en la forma en que se manejan los modelos en esta plataforma.

La configuración "trust_remote_code=True" utilizada por Unsloth Studio fue el punto crítico de esta vulnerabilidad, ya que permitía a la biblioteca subyacente "Transformers" descargar y ejecutar código Python personalizado mencionado en la configuración del modelo, incluso antes de que el modelo en sí fuera cargado. Este mecanismo, aunque puede facilitar ciertos flujos de trabajo, también abre la puerta a ataques que pueden comprometer la seguridad de los datos sensibles.

### Datos Factuales

Pillar Security notificó a Unsloth sobre esta vulnerabilidad a principios de junio, y la empresa reaccionó corrigiendo el problema en la actualización 2026.6.9 a finales del mismo mes. Tras realizar pruebas, Pillar verificó que el vector de ataque había sido cerrado. Sin embargo, la respuesta de Unsloth fue objeto de controversia, ya que la empresa sostenía que la exploración de malware de Hugging Face era un control adecuado sobre la superficie de ataque y que el Studio, al ser técnicamente una versión beta, debería ser excluido de la evaluación de seguridad. Pillar Security no compartió esta opinión y argumentó que la afirmación de Unsloth no abordaba adecuadamente la ejecución automática de código desde el repositorio.

Es relevante señalar que no se asignó un CVE a esta vulnerabilidad debido a que Unsloth declinó publicar el aviso de seguridad propuesto. A pesar de que no se ha detectado evidencia de explotación en el mundo real, la presencia de modelos maliciosos en plataformas como Hugging Face es un riesgo latente que los desarrolladores deben considerar.

### Impacto y Consecuencias

La implicación de esta vulnerabilidad es considerable, ya que permite a un atacante ejecutar código con los permisos del usuario afectado. En un entorno de desarrollo de inteligencia artificial, esto podría facilitar el acceso a datos de entrenamiento propietarios, artefactos de modelos y diversas credenciales vinculadas al proceso comprometido, como inicios de sesión en la nube o claves SSH. Esto no solo pone en riesgo la integridad de los datos, sino que también podría permitir la alteración de modelos y sus salidas de entrenamiento. Las organizaciones que operan en entornos de experimentación internos, que a menudo contienen datos sensibles y accesos privilegiados, se encuentran en una situación especialmente vulnerable.

### Contexto Histórico

Este incidente no es un caso aislado. La recurrencia de problemas relacionados con la ejecución de código remoto en herramientas de aprendizaje automático sugiere una brecha sistémica en la forma en que estas herramientas gestionan el contenido ejecutable de los modelos. En el transcurso de este año, se han reportado vulnerabilidades similares, incluyendo los errores LMDeploy CVE-2026-46432, vLLM CVE-2026-4944, e InstructLab CVE-2026-6859. Esto indica que la comunidad debe estar alerta y trabajar en medidas de seguridad más robustas para mitigar riesgos similares en el futuro.

### Recomendaciones

Ante la gravedad de esta vulnerabilidad, Pillar Security ha recomendado a los usuarios que actualicen Unsloth Studio a la versión 2026.6.9 o posterior. Más allá de esta actualización, es crucial que los desarrolladores traten los repositorios de modelos que cargan utilizando la configuración "trust_remote_code" como código no confiable en lugar de simplemente datos. También se aconseja asegurar que las herramientas en la cadena de producción no habiliten esta opción de forma automática. La situación actual destaca la necesidad de una mayor concienciación y educación sobre las implicaciones de seguridad de las configuraciones de herramientas en el ámbito del aprendizaje automático y la inteligencia artificial.

En resumen, el caso de Unsloth subraya la importancia de abordar las vulnerabilidades en las herramientas de desarrollo de inteligencia artificial. La convergencia de código y datos en este contexto requiere un enfoque riguroso y cauteloso para salvaguardar la seguridad de los sistemas y la integridad de los datos.

◢ VULNERABILIDADES ◣

Unsloth Studio Flaw Turns Routine Model Inspection Into Code Execution

⟫ 29/09/2026 ⟫ Alexander Culafi

Source: Dark Reading

Unsloth has fixed a vulnerability in its Web user interface (UI) front end that exposed users to arbitrary code execution through malicious models. Pillar Security's Ariel Fogel published a blog post today covering a flaw in Unsloth Studio. Unsloth Studio is the Web UI front end for Unsloth, a popular open source library used for fine-tuning and quantizing large language models (LLMs). According to the blog post, selecting a malicious model in Unsloth Studio could cause it to executePythoncode shipped within the model's Hugging Face repository. "The code ran from nothing more than a metadata check. Reading the model's config.json was enough to trigger the exploit; the backend never loaded the weights or ran inference — the act of inspecting a model was enough to run its code,"Fogel wrote. As the code ran with user permission, Fogel wrote that an attack utilizing this flaw targeting an enterprise AI development environment could expose proprietary training data, model artifacts, and a number of credentials tied to the compromised process, such as cloud logins or SSH keys. "An attacker could run code as the user, which could translate to stealing accessible data, altering models and training outputs, or using available credentials to access other systems," he wrote. "An internal experimentation environment can hold sensitive data and privileged access even when it serves no production traffic." Fogel tells Dark Reading that Pillar has seen no evidence of real-world exploitation or malicious model repositories targeting this particular configuration mechanism to date, though he emphasizes that other malicious campaigns have leaned onmalicious models uploaded to Hugging Face. Pillar traced the flaw to Unsloth Studio's use of the "trust_remote_code=True" setting while checking a model's configuration. The setting allowed the underlying "Transformers" library to download and execute custom Python code referenced by the model's config.json, even before the model itself was loaded. Pillar Security reported the flaw to Unsloth in early June, and Unsloth addressed the issue later that month in update 2026.6.9. Pillar tested the attack vector and confirmed it was closed. While Fogel credited Unsloth's maintainers for a fast response, the blog post claimed that Unsloth disputed aspects of the security assessment, "citing that Hugging Face's malware scanning was an adequate control on the attack surface, and that the Studio, which was technically listed as being in beta, should be excluded from consideration." The security vendor disagreed, arguing that Unsloth's claims fail to address Studio’s automatic execution of repository code. No CVE was assigned after Unsloth declined to publish the proposed security advisory, according to Pillar. Dark Reading attempted to contact Unsloth through X but has received no response by press time. Pillar recommended that users upgrade Unsloth Studio to 2026.6.9 or later, and more broadly to "treat model repositories you load using transformers library trust_remote_code as untrusted code rather than data, and make sure the tools in your pipeline never enable it on your behalf." As the blog author points out, there are use cases for the setting, but this is far from the first time it has been at the center of a vulnerability like this, even this year (see LMDeploy bug CVE-2026-46432, vLLM bug CVE-2026-4944, and InstructLab bug CVE-2026-6859). Fogel tells Dark Reading the recurrence of this issue suggests a systemic gap in how machine learningtoolshandle executable model content. Developers build useful workflows around artifacts that users generally think of as data, but those artifacts can also supply code. When a tool silently enables trust_remote_code, Fogel explains, it makes a consequential security decision on the user's behalf. "What makes the Unsloth case particularly concerning," he says, "is that the boundary was crossed during an action users reasonably understood as inspection."

← VOLVER A CIBERSEGURIDAD