Browsing a Model Was Enough. The 'trust_remote_code' Flaw That Won't Go Away

Key points

• Unsloth Studio fixed a code-execution flaw in update 2026.6.9, where simply inspecting a model's configuration file was enough to trigger malicious code.
• Three other AI tools disclosed the same class of vulnerability in 2026: InstructLab (CVE-2026-6859, April), vLLM (CVE-2026-4944, May), and LMDeploy (CVE-2026-46432, June), with LMDeploy still unpatched at time of CVE publication.
• The root cause in every case is a single setting, trust_remote_code=True, which tells an AI library to download and run custom Python code bundled inside a model file.

When a developer picks a model from a list, they expect to read about it, not run it. Unsloth Studio didn't honour that expectation.

Pillar Security researcher Ariel Fogel found that opening a model's configuration file inside Unsloth Studio, a browser-based tool used to fine-tune and customise large language models (programs that power AI assistants), triggered the execution of Python code hidden inside that file. Nobody clicked "run". The weights never downloaded, and inference never started. The act of inspecting a model was enough to fire its code.

How did a config file run code?

A config file read should be passive. Here it wasn't, because of a setting called trust_remote_code=True.

When an AI library loads a model from HuggingFace, a popular online repository where developers share AI models, the trust_remote_code setting controls whether the library may download and execute custom Python code the model's author has bundled alongside it. With the setting switched on, that code runs automatically. Unsloth Studio had it switched on during what users reasonably understood to be a simple inspection step.

Fogel found the code ran with the same permissions as the user running the tool. In a corporate AI development environment, that could mean access to proprietary training data, cloud credentials, SSH keys (digital passwords for remote servers), and model files built over months of expensive work.

Pillar reported the flaw to Unsloth in early June 2026. Unsloth patched it later that month in version 2026.6.9. No CVE identifier was assigned; Unsloth declined to publish a formal security advisory, according to Pillar, partly on the grounds that HuggingFace's own malware scanning was an adequate safeguard and that Unsloth Studio was still labelled beta software.

Is this a one-off mistake?

It isn't. The same setting is at the centre of three other high-severity vulnerabilities disclosed in 2026 alone.

The vLLM entry is pointed. CVE-2026-4944 was itself described in the National Vulnerability Database as an incomplete fix for two earlier CVEs, affecting separate code paths in model files. Patching once wasn't enough; the same assumption returned through different files.

For InstructLab, the linux_train.py script hardcodes trust_remote_code=True when loading models, meaning a remote attacker can achieve full system compromise by getting a user to train against or download a crafted model from HuggingFace.

Fogel's point, reported first in detail by Dark Reading, is that this keeps recurring because machine learning tools are built around artifacts that users mentally file as "data". Models feel like files. They can also supply executable code, and when a tool silently enables trust_remote_code, it makes a consequential security decision without telling anyone. Threat Vectr has tracked this pattern across eleven LLM-related stories since early July 2026, and the throughline is consistent: the assumption that a model is inert until you run it is wrong in ways that matter.

What should developers do right now?

Upgrade Unsloth Studio to version 2026.6.9 or later.

More broadly, treat any model repository loaded through the Transformers library as potentially executable code, not inert data. Audit your AI toolchain for any place where trust_remote_code=True appears as a default, and confirm it was set deliberately rather than inherited silently from a dependency.

Pillar says it has seen no evidence of real-world exploitation targeting Unsloth Studio. Four tools, four vulnerabilities, three months: the next hardcoded instance is probably already in someone's codebase.