正如其名称所暗示的，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和本地目录两条攻击路径。
