Mistral and TanStack Hit by Supply Chain Attack as SLSA Trust Model Fails

Mistral and TanStack Hit by Supply Chain Attack as SLSA Trust Model Fails

N
News Editor 01
2026-07-06 06:33:12
Mistral AI and TanStack-linked packages were compromised in a major supply chain attack, with malicious releases carrying valid SLSA attestations. The campaign exposed GitHub tokens, cloud credentials and password vaults, raising alarm across AI and crypto development ecosystems.

Mistral AI、TanStack及其相关开发者生态近日遭遇一次高危供应链攻击,事件不仅影响官方与热门软件包的分发安全,更因攻击样本携带有效的SLSA Build Level 3 provenance attestation而引发行业震动。这意味着,长期被视为软件供应链防线重要组成部分的来源证明机制,在现实攻击中已被成功绕过,安全信任模型面临严峻考验。

根据微软威胁情报团队5月11日披露的信息,攻击者入侵了PyPI上的mistralai软件包2.4.6版本,并在mistralai/client/__init__.py中植入恶意代码。相关代码会在导入时自动执行,从地址83.142.209.194下载第二阶段载荷至/tmp/transformers.pyz,随后在Linux���统上启动。该文件名刻意伪装成Hugging Face广泛使用的Transformers框架,具有较强迷惑性。

攻击规模扩大,波及AI与加密开发生态

研究人员将这轮行动归类为“Mini Shai-Hulud”攻击活动。安全平台SafeDep表示,此次行动在5月11日至12日期间共影响了170多个软件包,并发布了404个恶意版本。该漏洞编号为CVE-2026-45321,CVSS评分高达9.6,属于严重级别。

从攻击对象和窃取内容来看,这并非普通的软件投毒事件。恶意程序瞄准的资产包括GitHub令牌、AWS和GCP云凭证、Kubernetes服务账户、SSH密钥、npm发布凭证,以及1Password和Bitwarden密码库。对于大量同时参与AI项目、DeFi协议、钱包基础设施和交易系统开发的工程师而言,这类凭证一旦泄露,可能进一步引发代码仓库被接管、生产环境被入侵,甚至造成链上资产管理系统失守。

SLSA证明失效,供应链防御逻辑遭冲击

本次事件最值得警惕之处,在于恶意软件包带有有效的SLSA来源证明。SLSA provenance原本是一种依赖Sigstore生成的加密证书,用于验证软件包确实从可信源码构建而来。按照现有安全认知,这类证明应显著提升包分发环节的可信度。

然而,Snyk指出,针对TanStack的攻击成为首个已知的、携带有效SLSA provenance的恶意npm软件包案例。这意味着,单纯依赖构建证明、签名验证和自动化发布链条的防御体系已经不再充分。攻击者并非简单篡改最终产物,而是深入到了CI/CD与自动化工作流层面,从而让“合法构建”产出“恶意结果”。

报道显示,攻击者被识别为TeamPCP,其利用了三类问题形成攻击链:pull_request_target工作流配置错误GitHub Actions缓存投毒,以及从GitHub Actions运行进程内存中提取OIDC令牌。更具隐蔽性的是,恶意提交还伪装成Anthropic Claude GitHub App身份,并使用[skip ci]前缀绕过自动检查。

恶意程序具备多通道外传与破坏能力

这轮攻击所使用的Shai-Hulud蠕虫并非首次出现。报道提到,该恶意家族自2025年9月以来已经历多轮演化,并与2026年1月Trust Wallet事件相关,后者曾造成约850万美元损失。如今的新变种在窃密能力上进一步增强,开始针对密码管理器金库实施盗取。

在数据外传方面,恶意程序设计了三条冗余通道:一个仿冒域名git-tanstack.com、去中心化通信网络Session,以及利用被盗令牌创建的Dune主题GitHub仓库。这种多路径回传机制意味着,即便某一渠道被封堵,攻击者仍可能保留持续窃取能力。

值得注意的是,恶意程序在检测到俄语语言设置时会主动退出;而在被定位为以色列或伊朗的系统上,则有六分之一概率执行递归删除命令rm -rf /。这表明其不只是信息窃取工具,也可能在特定条件下演化为破坏性载荷。

Mistral回应与开发者应对措施

Mistral于5月12日发布安全公告称,其核心基础设施未被攻破,事件源头是一台受损的开发者设备,并与更大范围的TanStack供应链攻击活动相关。受影响的mistralai==2.4.6版本在UTC时间5月12日零点后不久上传,随后PyPI对项目进行了隔离处理。

除Python生态外,npm上的相关软件包也受到波及,包括@mistralai/mistralai@mistralai/mistralai-azure@mistralai/mistralai-gcp。这些包在下架前曾短暂可用数小时,但考虑到其庞大的用户基础,风险窗口已经足以造成广泛传播。报道指出,受影响软件包的累计每周下载量超过5.18亿次,其中仅@tanstack/react-router每周下载量就达1270万次

对于已经安装受影响版本的开发者,当前最直接的处置建议包括:立即轮换云凭证、GitHub令牌、SSH密钥和交易所API密钥,并检查.claude/.vscode/目录中是否存在持久化钩子。对于管理链上资产、做市系统或托管钱包服务的团队而言,这一步骤尤其关键,因为任何被窃取的自动化部署密钥都可能迅速转化为资金风险。

市场影响:加密行业需重估“开发工具链风险”

从市场角度看,此次事件虽然尚未披露直接链上资金损失,但其对加密行业的警示意义非常明显。当前大量区块链项目高度依赖开源软件包、云基础设施与自动化CI/CD流程,一旦上游AI开发工具或前端框架被投毒,风险就可能顺着代码依赖链迅速蔓延至钱包、交易平台、跨链桥和数据分析服务。

更深层次的影响在于,投资者与项目方可能需要重新评估技术栈的供应链可信度。过去,市场往往更关注智能合约审计、私钥托管和链上监控,而对开发过程中的包管理器、构建证明和工作流权限控制重视不足。此次攻击显示,“可信签名”不等于“可信结果”,未来安全预算或将更多流向构建隔离、最小权限、依赖审计和运行时检测。

总体来看,这起事件不仅是Mistral和TanStack的安全事故,更是整个AI与加密开发生态的一次压力测试。随着攻击者开始系统性利用开发工具链中的信任关系,行业必须接受一个现实:传统的软件供应链验证框架已不足以单独承担防线职责,安全策略需要向“持续验证”和“假设已遭入侵”模式加速转型。

This article was originally published by Bit.Fan. For more cryptocurrency news and market insights, visit www.bit.fan.
300

Disclaimer:

The market information, project data, and third-party content displayed on this platform are for industry information sharing only and do not constitute any form of investment advice or return commitment.

Cryptocurrency trading carries high risks. Users should fully assess their risk tolerance and make independent decisions. All profits, losses, and legal responsibilities are borne by the users themselves.