正如其名稱所暗示的，AI模型訓練工具Unsloth在開發者選擇模型時所做的工作，超出了用戶的預期：它還會允許任意代碼在用戶的機器上執行。
Pillar Security發現，僅僅是在Unsloth Studio中選擇一個模型，就會導致該應用從模型倉庫下載並執行Python代碼。這可能使攻擊者利用精心構造的惡意模型，在開發者的系統上執行惡意代碼。
研究員Ariel Fogel在Pillar的部落格文章中表示："這段代碼僅憑一次元數據檢查就被觸發運行了。讀取模型的config.json文件就足以觸發漏洞；後端從未加載過模型權重，也沒有運行推理過程。"
Fogel表示，該代碼會以用戶的權限運行，這可能導致企業AI開發環境中的專有訓練數據、模型文件、Hugging Face令牌、SSH密鑰或可訪問的雲憑證遭到泄露。
Unsloth Studio是一個目前處於測試版階段的網頁界面。據報道，Unsloth的維護者以此狀態為由，在6月修復該漏洞後拒絕發布安全公告或為該漏洞申請CVE編號
。Pillar對此理由提出異議，指出存在漏洞的Studio代碼是作為標準的、正式可用的PyPI上"unsloth"軟體包的一部分發布的，用戶無需選擇測試版或預發布版本，僅通過常規的"pip install unsloth"命令即可安裝。
Unsloth使用了Hugging Face的trust_remote_code選項，該選項允許模型在需要時攜帶自己的Python代碼。
Fogel表示，這一機制本身並不一定危險。一些正規的Hugging Face模型，包括IBM Granite Speech和Vision、DeepSeek-OCR、ChatGLM以及早期的Qwen版本，都需要自定義代碼才能正常運行。
問題在於，Unsloth在常規模型檢查過程中會自動啟用該功能，而不是要求用戶明確選擇是否運行遠程代碼。在補丁發布之前，當Unsloth使用Hugging Face的Transformers模型加載功能來獲取被檢查模型的資訊時，"trust_remote_code"選項默認是開啟的。
Unsloth的維護者還指出，Hugging Face自身對含有自定義代碼的模型有惡意軟體掃描和警告機制，這也是他們不將該問題視為漏洞的另一個原因。Pillar反駁稱，Hugging Face的防護措施大多只是黑名單機制，其概念驗證（PoC）代碼在掃描時並未被標記，但一旦經由Unsloth處理，就可能獲取惡意的第二階段載荷。
不過，Fogel強調，這並非Hugging Face本身的漏洞，而是Unsloth使用trust_remote_code方式存在的問題。
此次修復不僅僅是改變一個設置選項。Pillar最初建議在模型檢查路徑上將trust_remote_code固定設為False，因為該路徑只需要從config.json中讀取聲明性資訊即可。而Unsloth最終的修復措施更進一步。
在2026.6.9版本中，Studio被修改為不再直接從Hugging Face啟用任意模型加載，也不再信任本地模型文件中的遠程代碼。Fogel表示，他們獨立重新測試了該版本，確認Hugging Face和本地目錄兩條攻擊路徑均已被封堵。
Pillar敦促用戶升級到已修復的版本，即便用戶從不啟動Studio、只使用Unsloth核心功能也應如此。此外，該公司建議用戶審查自身的大語言模型工作流程，排查是否存在不必要的trust_remote_code=True設置。
Fogel警告稱："攻擊者的攻擊時間窗口正在不斷縮短，因為自動化倉庫掃描、智能體式的漏洞利用以及有組織的供應鏈攻擊活動，能夠比AI普及之前更快地將一個看似無害的auto_map模組武器化。"
Q&A
Q1：Unsloth的安全漏洞具體是什麼問題？
A：開發者在Unsloth Studio中僅選擇一個模型，應用就會自動從模型倉庫下載並執行Python代碼，攻擊者可利用精心構造的惡意模型讓惡意代碼在開發者機器上執行，而無需加載模型權重或運行推理。
Q2：這個漏洞可能導致哪些數據泄露？
A：該代碼會以用戶權限運行，可能導致企業AI開發環境中的專有訓練數據、模型文件、Hugging Face令牌、SSH密鑰以及可訪問的雲憑證遭到泄露。
Q3：Unsloth是如何修復這個漏洞的？
A：在2026.6.9版本中，Unsloth修改了Studio，使其不再直接從Hugging Face啟用任意模型加載，也不信任本地模型文件中的遠程代碼，封堵了Hugging Face和本地目錄兩條攻擊路徑。
