Vulnerabilities

Unsloth is a popular open source library for fine-tuning and quantizing large language models (LLMs), and Unsloth Studio is the browser interface and backend that ships inside the same unsloth package. Pillar Security researcher Ariel Fogel found that choosing a model in Studio was enough to make the backend download and run Python code from that model's Hugging Face repository. No weights had to load, no training or inference had to start, and the user was never asked to approve remote code.

Unsloth fixed it on June 18 in release 2026.6.9, after a private report in early June under GitHub advisory GHSA-pc2m-72c4-r38q. The maintainers declined to publish an advisory or request a CVE, so vulnerability scanners and dependency alerts have nothing to match on. If your data science or ML team runs Studio on a GPU workstation or a shared training server, check the installed version yourself.

How it works

A Hugging Face model repository holds more than weights. Its config.json describes the architecture, and it can carry an auto_map field that points AutoConfig, AutoModel or the tokenizer at Python files stored next to the weights. Some legitimate models need this because their architecture is not built into the Transformers library. Transformers only imports those files when the caller passes trust_remote_code=True; with the default of False it refuses.

In affected Studio releases, the backend function load_model_config() set trust_remote_code to True by default. The capability and vision checks that run when a user picks a model called it without overriding that default. Those checks sit behind two HTTP endpoints, GET /api/models/config/{model_name:path} and GET /api/models/check-vision/{model_name:path}, and the UI calls them as soon as a model is chosen.

So the sequence was: the user types or pastes a repository name, Studio fetches its config.json to see what kind of model it is, Transformers follows auto_map, and the attacker's module is imported and executed inside the Studio backend process. In Fogel's words, "the code ran from nothing more than a metadata check." The same flaw also applied to models loaded from a local directory.

The code runs with the permissions of whoever started Studio. On a typical ML workstation that account has a Hugging Face token in its environment or cache, SSH keys for the training cluster, cloud credentials for storage buckets, and read and write access to proprietary training data and model artifacts. Pillar lists all of these as exposed.

What attackers are doing

None of the reports describe exploitation in the wild, and Pillar's work was a coordinated disclosure with a proof of concept shared privately. The setup an attacker needs is cheap, though: a public Hugging Face repository with a plausible name, a crafted config.json and one Python file. Getting someone to try it takes a link in a forum post, a model card that claims a better fine-tune of a well-known base model, or a name one character off from a popular repository.

The pattern has come up in other AI tools this year. LMDeploy, a toolkit for compressing and serving LLMs, received CVE-2026-46432 for hardcoding trust_remote_code=True in its model loading code. Tools such as vLLM leave it to the operator to pass --trust-remote-code explicitly. Studio enabled it by default and moved the trigger to model selection, a step users do not think of as running code.

What to do

1. Upgrade to 2026.6.9 or later

Every unsloth release before 2026.6.9 that includes Studio is affected. Run pip show unsloth in each Python environment that runs Studio, and upgrade with pip install --upgrade unsloth. Check container images and notebooks with pinned requirements as well, since a pinned old version will keep coming back on rebuild. In 2026.6.9 Studio no longer loads arbitrary models straight from Hugging Face and no longer trusts remote code from local model files. Pillar retested that release and confirmed both the Hugging Face and the local directory paths are closed.

2. If you cannot upgrade today

Stop selecting models in Studio from repositories you have not reviewed. Before anyone picks a new model, open its config.json on Hugging Face and look for an auto_map key and any .py files in the file list. Setting HF_HUB_OFFLINE=1 in the environment that launches Studio stops the Hugging Face libraries from fetching anything new from the Hub, which blocks the remote path but leaves the local directory path open.

Run Studio under a dedicated account without SSH keys or cloud credentials, ideally in a container that mounts only the datasets and output directory it needs. This limits what a malicious module can reach. It does not stop the code from running.

3. Check whether untrusted code already ran

• Transformers copies remote code it imports into ~/.cache/huggingface/modules/transformers_modules/ for the user that ran Studio (or the path in HF_MODULES_CACHE, if set). Every folder there corresponds to a repository whose code was imported. Match each one to a model your team meant to use.
• Downloaded repositories sit under ~/.cache/huggingface/hub/ as models--<owner>--<name>. huggingface-cli scan-cache lists them. Look for owners you do not recognise, then for .py files in their snapshots folders.
• Read any Python file you cannot account for. Code that reads environment variables, ~/.ssh, ~/.aws or ~/.cache/huggingface/token, or that opens network connections, is the signal to treat the host as compromised.
• Check outbound connections from the GPU host in your firewall or proxy logs around the times new models were tried, and look for new cron entries, systemd units or authorized_keys lines under the Studio account.

4. Rotate and clean up if you find anything

Revoke and reissue the Hugging Face token under Settings, Access Tokens on huggingface.co, then replace the SSH keys and cloud credentials that account could read. Rebuild the host or container from a clean image. Review models and checkpoints written after the suspect model was loaded, because an attacker with write access to your output directory can alter weights or training results without leaving an obvious trace.

The wider lesson

AI tooling tends to land on workstations through a pip install, outside the asset inventory and patch process that covers servers. A flaw fixed without a CVE then never shows up in a scanner, so somebody has to watch the project's release notes. Add the ML stack to the inventory, and treat any tool that touches model repositories as running untrusted code: search your own code and configs for trust_remote_code=True and require a reason for each one.

Our AI native systems team reviews how model pipelines load and run third party code, and a red team and code review engagement can trace where a setting like trust_remote_code reaches in your stack. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Pillar Security, Dark Reading, InfoWorld, Cyber Security News, Cyberpress, GBHackers, GitLab advisory for CVE-2026-46432.