Reported by 6 outlets
Unsloth Fixes Arbitrary Code Execution Flaw Triggered by Malicious Hugging Face Models
Why this score
- Breadth
- 2.00 / 2.0 · 6 sources
- Authority
- 1.50 / 2.0 · best outlet weight
- Severity
- 0.50 / 5.0 · CVSS + content signals
- Velocity
- 0.00 / 2.0 · updates in 48h
- Pickup speed
- 0.01 / 0.6 · time to second source
- Recency
- × 0.00 temporal multiplier
- Community
- + 0.00 / 1.5 · reddit signal
- Score
- 0.0 / 10 = base × recency + community
Desk analysis
The news frame understates this twice over: it reads as a patched bug in a beta UI, but the vulnerable path ran attacker Python as the logged-in operator before any weights loaded, and the whole thing was fixed in June, not September. In Unsloth Studio's backend, studio/backend/utils/models/model_config.py defaulted load_model_config to trust_remote_code=True, the capability probes behind GET /api/models/config/{model_name:path} and GET /api/models/check-vision/{model_name:path} inherited that default, and a transformers-5 subprocess branch hardcoded it. A Hugging Face repo whose config.json carried an auto_map entry pointing AutoConfig at a sibling Python module was therefore downloaded and imported the moment an operator selected it in the model picker, before weights, inference, or the user's own trust_remote_code setting (default False) were ever consulted. Ariel Fogel of Pillar Security reported it privately in early June 2026 via GitHub Security Advisory GHSA-pc2m-72c4-r38q; maintainers shipped commit 0533efe3, "Harden model fetching", on June 18, and unsloth 2026.6.9 landed on PyPI on June 22 with the vector closed. No CVE exists because the maintainers declined to publish the advisory, and the repo's security tab shows zero published advisories.
The missing CVE is the story. This is the same defect family as CVE-2026-46432 in LMDeploy, CVE-2026-4944 in vLLM, and CVE-2026-6859 in InstructLab, all tooling that enabled trust_remote_code=True on the user's behalf, and a related transformers Trainer fix (CVE-2026-1839) came out of the same hardening pass. Those carry identifiers that feed scanner and KEV-style triage; this one carries nothing, so exposure is invisible to feeds and can only be found by checking the installed unsloth version, where anything at or before 2026.5.10 with Studio launched is affected. The victim profile is worse than the beta label implies: these are GPU hosts holding Hugging Face tokens, SSH keys, and cloud credentials, code executed with the operator's privileges, and multi-user setups, Colab use, or a -H 0.0.0.0 binding widen the reach. Unsloth is not niche either: Databricks ships it in its AI v5 environment and Hugging Face counts it as the third-largest source of model derivatives on the Hub, so the package is present in many environments that never deliberately run Studio.
Upgrade to 2026.6.9 or later; the current release is 2026.9.12, and recent installer pins already require unsloth>=2026.9.7. Inventory with pip show unsloth across every data science host and CI image, because the vulnerable code shipped in the ordinary pip install unsloth wheel rather than a separate beta package. On hosts that ran Studio before the June fix, hunt for the Pillar proof-of-concept artifacts, a calculator process spawned by the Studio backend and a ~/UNSLOTH_POC_RCE.txt marker file, then treat Hugging Face tokens and SSH keys on those hosts as compromised and rotate them. Structurally, audit every place trust_remote_code=True is reachable in your ML toolchain, pin model revisions by commit hash, prefer safetensors, and treat Hugging Face's scanner as a tripwire rather than a boundary, since the PoC passed it by being benign at rest and staging execution later.
Two developments would move this assessment. First, in-the-wild use: an auto_map module that passes Hub scanning and stages a second payload at execution time would defeat the control maintainers leaned on, so telemetry for unexpected Python imports or outbound connections from Studio backends after a model selection is the specific hunt. Second, Unsloth reversing course and publishing the advisory would hand defenders a CVE id to wire into scanners and signal the beta carve-out is not holding; either event changes patch pressure across the long tail of environments still frozen on pre-June wheels.
Timeline
-
original reporting
Unsloth Fixes Arbitrary Code Execution Flaw Triggered by Malicious Hugging Face Models
gbhackers.com · 13d ago · September 30th, 2026
Unsloth has addressed a critical arbitrary code execution vulnerability in its Studio web interface. This flaw allowed a malicious Hugging Face model repository to execute attacker-controlled Python code simply by a user selecting or inspecting it. Unsloth resolved the issue in version 2026.6.9, and users running Studio are urged to update immediately. Unsloth Fixes Arbitrary […] The post Unsloth Fixes Arbitrary Code Execution Flaw Triggered by Malicious Hugging Face Models appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform .
-
update from github.com
Commit 0533efe3: Harden model fetching (#6391)
github.com · 118d ago · June 18th, 2026
The vendor fix commit, dated June 18, 2026 per the Pillar disclosure timeline. It adds a consent gate that scans a model's auto_map repository code before execution, keeps capability detection code-free by reading raw config.json instead of AutoConfig, adds a picklescan and ClamAV backed malware gate over load paths, and removes the blanket trust remote code toggles from chat and export. The unsloth repo's security advisories tab shows zero published advisories, consistent with the maintainer decision not to publish the GHSA and assign no CVE.
-
update from pypi.org
unsloth 2026.6.9 release on PyPI
pypi.org · 113d ago · June 22nd, 2026
The unsloth-2026.6.9 wheel was uploaded to PyPI on 2026-06-22T16:13:03Z, roughly three months before public disclosure, meaning the patch has been available since late June and only environments frozen on earlier wheels remain exposed. PyPI shows 2026.5.10, the last release with the vulnerable Studio path per the researcher, was uploaded 2026-06-01, and the current release is 2026.9.12.
-
update from pillar.security
Look, Don't Load: Model Inspection in Unsloth Studio Leads to Critical Arbitrary Code Execution
pillar.security · 15d ago · September 29th, 2026
The original researcher disclosure, published September 29, 2026 by Ariel Fogel of Pillar Security, one day before the story's first_seen. It documents the full mechanism: the Studio backend's load_model_config defaulted trust_remote_code=True, the capability probes at /api/models/config/{model_name:path} and /api/models/check-vision/{model_name:path} inherited it, and a repo config.json auto_map entry pointing AutoConfig at a sibling Python file executed on mere model selection. The post also gives the disclosure timeline (private report early June 2026 via GHSA-pc2m-72c4-r38q, fix commit 0533efe3 on June 18, fix verified in 2026.6.9) and notes the maintainers declined to publish the advisory, so no CVE was assigned.
-
update from cyberpress.org
Critical Unsloth Studio Flaw Executes Malicious Code When Users Select Hugging Face Models
cyberpress.org · 13d ago · September 30th, 2026
Researchers at Pillar Security found that the flaw affected the browser-based Studio interface included with the standard unsloth Python package. Although Studio was described as beta, the vulnerable component was delivered through normal pip install unsloth deployments, placing it within potentially sensitive AI development and fine-tuning environments. Critical Unsloth Studio Flaw The vulnerability did not require a victim to load model weights, begin inference, or intentionally enable execution of model-supplied code. A malicious repository could include an auto_map entry in its configuration that pointed Transformers components, such as AutoConfig , to custom Python files stored in the same repository. When the backend processed that configuration with trust_remote_code=True , the Transformers library downloaded and imported the supplied Python module. As a result, a seemingly harmless metadata or capability check became a code-execution event. Pillar Security demonstrated that its proof-of-concept repository could launch a calculator appli
-
mentioned by www.darkreading.com
Unsloth Studio flaw enables code execution via model inspection
www.darkreading.com · 13d ago · September 30th, 2026