Unsloth Studio executed a model's Python code during a routine config check
Unsloth fixed Studio in version 2026.6.9 after Pillar Security showed that reading a malicious model's config.json could run an attacker's Python code. Unsloth disputed parts of the finding and declined to publish an advisory, so no CVE was assigned.
The Watch · Security desk
What happened
- Studio's model check called the Transformers library with trust_remote_code=True, which let it download and run custom Python referenced in config.json before any weights loaded.
- The code ran with the user's permissions, putting proprietary training data, model artifacts and credentials such as cloud logins and SSH keys within reach.
- Pillar reported the flaw in early June, Unsloth shipped the fix later that month, and Pillar confirmed the attack path was closed.
- The same setting was at the center of LMDeploy CVE-2026-46432, vLLM CVE-2026-4944 and InstructLab CVE-2026-6859 this year.
Why it matters
- Who's exposed exposure On unpatched Studio installs, whoever publishes a Hugging Face repository chooses code that runs on the machine of anyone who browses to that model.
- What it limits constraint Without a CVE, scanners and patch dashboards keyed to CVE identifiers have nothing to flag, so finding pre-2026.6.9 Studio installs takes a manual version check.
- Who has to decide decision Pillar's advice makes trust_remote_code an install decision: any pipeline tool that sets the flag for the user has to be found and reviewed the way an untrusted package would be.
Next story · Build · 6h ago
Reflection's 501B-parameter Beam coding model launches on SageMaker JumpStartConfirmed2 publishers
Studio is the web front end for Unsloth, an open source library for fine-tuning and quantizing large language models [1]. For the attack to work, the victim only has to select a malicious model in that interface [2]. "The code ran from nothing more than a metadata check. Reading the model's config.json was enough to trigger the exploit," Pillar Security's Ariel Fogel wrote in the disclosure post [3].
Fogel told Dark Reading that Pillar has seen no real-world exploitation and no malicious repositories aimed at this configuration mechanism [13]. He also said other campaigns have used malicious models uploaded to Hugging Face [13]. No actor has been tied to this flaw.
A working payload runs as the developer [5]. Fogel's list of outcomes included "altering models and training outputs" and using available credentials to reach other systems [6]. "An internal experimentation environment can hold sensitive data and privileged access even when it serves no production traffic," he wrote [7].
According to Pillar's post, Unsloth disputed the 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" [17]. Pillar's reply was that neither argument deals with Studio executing repository code automatically [18]. Unsloth did not respond to Dark Reading's request for comment, sent through X [14].
Counting Studio, at least four AI development tools this year have had code-execution bugs centered on trust_remote_code [16]. Fogel told Dark Reading the recurrence points to a systemic gap in how machine learning tools handle executable model content [11]. Users treat model artifacts as data, but those artifacts can also supply code. In his account, a tool that silently enables the flag makes a consequential security decision on the user's behalf [11].
The Unsloth case differs in where the code ran. What stood out, he said, "is that the boundary was crossed during an action users reasonably understood as inspection" [12].
What to watch
- Whether Unsloth publishes an advisory or a CVE is assigned to the Studio flaw after the fact.
- Any Hugging Face repository found using config-time custom code against inspection features; Pillar says it has seen none so far.
- Other model-browsing or metadata tools found calling Transformers with trust_remote_code enabled by default.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Not scored
- Hype gap+10
- Incentives60
- Confidence68
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Unsloth Studio is the Web UI front end for Unsloth, a popular open source library used for fine-tuning and quantizing large language models.
- [2]
According to Pillar Security's blog post, selecting a malicious model in Unsloth Studio could cause it to execute Python code shipped within the model's Hugging Face repository.
- [3]
"The code ran from nothing more than a metadata check. Reading the model's config.json was enough to trigger the exploit"
- [4]
Pillar traced the flaw to Unsloth Studio's use of trust_remote_code=True while checking a model's configuration; the setting allowed the Transformers library to download and execute custom Python code referenced by the model's config.json, even before the model itself was loaded.
- [5]
The code ran with user permission; an attack on an enterprise AI development environment could expose proprietary training data, model artifacts, and credentials tied to the compromised process such as cloud logins or SSH keys.
- [6]
"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"
- [7]
"An internal experimentation environment can hold sensitive data and privileged access even when it serves no production traffic."
- [8]
Pillar Security reported the flaw to Unsloth in early June; Unsloth addressed it later that month in update 2026.6.9, and Pillar tested and confirmed the attack vector was closed.
- [9]
No CVE was assigned after Unsloth declined to publish the proposed security advisory, according to Pillar.
- [10]
Pillar recommended upgrading 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."
- [11]
Fogel told Dark Reading the recurrence suggests a systemic gap in how machine learning tools handle executable model content; artifacts users think of as data can also supply code, and when a tool silently enables trust_remote_code it makes a consequential security decision on the user's behalf.
- [12]
"is that the boundary was crossed during an action users reasonably understood as inspection."
- [13]
Fogel told Dark Reading that Pillar has seen no evidence of real-world exploitation or malicious model repositories targeting this configuration mechanism to date, though other malicious campaigns have used malicious models uploaded to Hugging Face.
- [14]
Dark Reading attempted to contact Unsloth through X and received no response by press time.
- [15]
trust_remote_code has been at the center of similar vulnerabilities this year, including LMDeploy CVE-2026-46432, vLLM CVE-2026-4944 and InstructLab CVE-2026-6859.
- [16]
At least four AI development tools this year have had code-execution bugs centered on trust_remote_code: LMDeploy, vLLM, InstructLab and Unsloth Studio.
- [17]
According to Pillar's post, Unsloth disputed aspects of the 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."
- [18]
Pillar disagreed, arguing that Unsloth's claims fail to address Studio's automatic execution of repository code.
Sources
2 independent publishers whose own reporting we read for this story.
- csoonline.comUnsloth’s model picker had a code-execution problem | CSO Online
1 article · September 30, 2026
- darkreading.comUnsloth Studio Flaw Turns Routine Model Inspection Into Code Execution
1 article · September 29, 2026