Unsloth’s model picker had a code-execution problem

True to its name, AI-model-training tool Unsloth would do more work than it was asked to when developers checked out a model: It would also allow arbitrary code to execute on their machines. Pillar Security found that simply selecting a model in Unsloth Studio caused the application to download and execute Python code from the model repository. This could potentially allow attackers to use a specially crafted model to get malicious code executed on a developer’s system. “The code ran from nothing more than a metadata check,” researcher Ariel Fogel said in a post on Pillar’s blog . “Reading the model’s config.json was enough to trigger the exploit; the backend never loaded the weights or ran inference.” The code would run with the user’s permission which, Fogel said, could expose proprietary training data, model artifacts, Hugging Face tokens, SSH keys, or accessible cloud credentials in an enterprise’s AI development environment. Unsloth Studio is a web-based interface that is currently in beta, a status Unsloth’s maintainers cited when they reportedly declined to publish a security advisory or have a CVE assigned to the flaw after fixing it in June . Pillar contests that reasoning, pointing out that the vulnerable Studio code ships as part of the standard, generally available “unsloth” package on PyPI and can be installed through an ordinary “pip install unsloth” without selecting a beta or prerelease version. Transformers setting opened the door Unsloth uses Hugging Face’s trust_remote-code option, which allows a model to bring along its own Python code when needed. That’s not necessarily dangerous by itself. Some legitimate Hugging Face models, including IBM Granite Speech and Vision, DeepSeek-OCR, ChatGLM, and earlier Qwen releases, need custom code to work properly, Fogel said. The problem was that Unsloth enabled the feature automatically during a routine model check rather than requiring the user to explicitly opt into running remote code. Before the patch, “trust_remote_code” was turned on by default when Unsloth used Hugging Face’s Transformers model-loading functionality to obtain information about a model being inspected. Unsloth’s maintainers also pointed to Hugging Face’s own malware scanning and warnings for models containing custom code as another reason for not treating the issue as a vulnerability. Pillar counters that Hugging Face’s protections are mostly blocklists and that its proof-of-concept (PoC) code was not flagged when scanned but could have fetched a malicious second-stage payload only when processed by Unsloth. However, Fogel stressed that this is not a Hugging Face vulnerability, but an issue with how Unsloth uses trust_remote_code. The fix went beyond flipping the setting. Pillar initially recommended pinning trust_remote_code=False on the model-checking path because that path only needed to read declarative information from config.json. Unsloth’s eventual fix went further. In version 2026.6.9, Studio was changed to no longer enable arbitrary model loading directly from Hugging Face and to not trust remote code from local model files. Fogel said it independently retested the version and confirmed that both the Hugging Face and local-directory attack paths were closed. Pillar urged users to upgrade to the fixed version, even if they never launch Studio and only use Unsloth core. Additionally, the company advised to audit LLM workflows for unnecessary occurrences of trust_remote_code=True. “The time-to-exploit for attackers keeps shrinking, because automated repo scanning, agentic exploitation, and organized supply-chain campaigns can weaponize a benign-looking auto_map module even faster than before the adoption of AI,” Fogel warned. This article first appeared on InfoWorld .