2026 年 5 月 25 日，SlowMist 旗下 MistEye 把一轮潜伏已久的攻击拉进了聚光灯：攻击者没有直接撬门入室，而是绕到后方仓库，在 npm、PyPI 与 crates.io 三大软件包注册表中同步投放恶意包。监测结果显示，至少 34 个恶意包、384 个以上相关版本或工件已经被植入这些公共依赖链路，它们伪装成常见的开发组件，精准对准加密货币、DeFi、Solana、Sui/Move 以及 AI 开发者。表面上，开发者依旧通过熟悉的命令安装依赖，实际上却在把未知代码拉进自己的构建体系；长期以来建立在公共注册表之上的“默认信任”被这次跨注册表投毒撕开一道口子，连通链上与 AI 生态的同一条依赖链开始摇晃，对整个加密开发环境的安全假设提出了直接挑战。
三大注册表中毒：34个恶意包如何潜入
这不是某个角落里悄悄扔进一个可疑包那么简单。SlowMist 旗下 MistEye 披露，攻击者选择的是 npm、PyPI 与 crates.io 三大主流软件包注册平台同步下手，把同一套恶意逻辑拆分为不同语言、不同生态的“组件”，在多个注册表里平行铺开。此前供应链攻击多集中在单一注册表，本次三平台同时中毒的情况相对罕见，一旦开发者在多语言、多框架项目中混用这些仓库，就等于把同一条受污染的依赖链，从前端脚本一路接到后端服务。
为了不被第一时间识破，这些恶意包在描述与命名上刻意伪装成正常的开发或安全工具：有的宣称是为加密货币与 DeFi 提供 SDK 或调试组件，有的打着 Solana、Sui/Move 支持库的旗号，还有的号称面向 AI 场景的开发辅助与安全检测。攻击者正是押注在公共注册表“默认可信”的使用习惯上，让开发者在毫无防备的情况下，将这些包拉进构建流程。MistEye 目前确认至少 34 个恶意包、384 个以上版本或构建工件被投放，这种按版本迭代、批量铺货的方式，显示攻击并非一次性试探，而是一场有计划、可持续的供应链渗透行动。
从DeFi到Solana：被瞄准的开发者战场
在 MistEye 披露的攻击谱系中，被点名的不是单一项目，而是一整条开发者链路：负责加密货币与 DeFi 项目的后端工程师，负责 Solana、Sui/Move 等公链生态的合约与工具开发者，以及同样依赖开源生态的 AI 开发者，都被纳入同一轮打击范围。对这些人而言，npm、PyPI、crates.io 不是“可选资源库”，而是日常构建钱包插件、节点运维脚本、合约交互 SDK 乃至模型服务后端的基础设施，一旦从这里把恶意依赖带入生产环境，就等于在关键业务链路里预埋了一段外部不可控的代码。
在链上世界，这种预埋带来的影响，很少停留在“开发机被入侵”这种层面。钱包签名组件如果被替换，用户发起的每一笔交易都可能在本地被篡改；节点服务和监控脚本被植入后门，运营团队看到的状态就不再可信；合约后端和 AI 服务网关一旦被恶意依赖劫持，接口认证、私钥调用、任务队列等敏感操作就可能被旁路复制或重放。攻击者瞄准的，正是这些表面上只是“开发工具”的依赖，一旦顺利落地，它们就能顺着 Web3 项目的工程流水线，悄无声息地靠近真实资产与数据所在的安全边界。
单点防守失效：跨注册表投毒放大风险
当恶意依赖不再局限于某一个仓库，原本“守住一扇门”的思路就立刻失效了。此前开源社区遭遇的供应链攻击，多是集中在单一注册表，比如只在 PyPI 或只在 npm 上撒网，安全团队可以针对该平台加固检测规则、清理恶意包，再辅以开发者侧的白名单与镜像源管控。而这一次，攻击者同时在 npm、PyPI 与 crates.io 上投放至少 34 个恶意包及数百个版本工件，意味着无论是链上项目后端用到的 JavaScript 组件，还是 AI 工程脚本中的 Python 依赖，甚至底层 Rust 库，都可能在不同环节被同一个攻击者“接力”截胡。
据 SlowMist 披露和后续安全圈反馈，多家机构已经开始联动分析这轮跨注册表攻击，但各自的检测范围、处置名单和加固方案尚未完全公开，开发者端能直接感知到的防护仍然有限。更现实的问题是，加密、DeFi、Solana、Sui/Move 以及 AI 项目团队在日常开发中习惯默认信任这些公共注册表，把版本号写进配置文件、让 CI/CD 自动拉取依赖，一旦攻击面跨平台扩散，单靠某一家注册表的审核或某一款安全扫描工具，很难覆盖整条工程流水线的所有入口，默认信任公共注册表的旧有模型正在被这类跨注册表投毒事件迅速掏空。
团队该怎么活：开发流程里的安全补课
对加密与 AI 项目团队来说，这轮事件已经把话讲得很明白：公共注册表只是下载源，不是安全边界。SlowMist 统计到至少 34 个恶意包、384 个以上版本被投放到 npm、PyPI、crates.io，多次迭代都能被混入，说明“升级依赖 = 自动安全”的直觉根本站不住脚。团队需要把依赖管理拉回到自己的工程体系里：核心仓库必须启用白名单和版本锁定，明确哪些包、哪些版本允许进入生产构建；任何新增或升级依赖，都要通过代码审计或安全评审，而不是让开发者随手在配置文件里加一行版本号就直接进入 CI/CD。
对链上项目尤其如此。合约部署脚本、节点运维工具、关键构建链路，理应和普通业务代码分层管理：一套更保守的更新节奏，一套更严格的审核和回滚预案。加密与 DeFi 团队早已习惯用自动化流水线在多环境拉依赖，一旦被恶意包污染，就是“开发机 → 测试网 → 主网”全链路扩散；AI 团队同样高度依赖开源包，把模型训练、推理服务、数据处理脚本都堆在第三方库之上，如果没有把依赖审计纳入常规流程，就等于把项目的核心基础设施交给不受控的外部版本号来决定。
供应链攻防长期战：下一次警报会在哪里响
2026-05-25 这轮由 SlowMist 旗下 MistEye 披露的跨注册表供应链攻击，把加密与 AI 开发者共同踩在的那条“默认信任”链路照得一清二楚：攻击者能在 npm、PyPI、crates.io 同时布下至少 34 个恶意包及 384 个以上相关版本，说明供应链已经不是一次性的事故，而是会被反复试探的长期战场。更棘手的是，现有公开信息尚未披露攻击者身份、具体受影响项目或用户数量，多家安全机构虽然已经介入，但清理和防御升级仍在推进中，这意味着今天看到的只是攻击面的一部分。接下来值得长期盯紧的，有三条线索：一是 npm、PyPI、crates.io 等注册表平台是否会在审核机制、包签名与回滚流程上做出实质强化，二是 SlowMist 等安全厂商能否把这次跨生态投毒的检测经验固化成更敏锐的监控能力，三是加密与 DeFi 团队以及 AI 团队是否会在行业层面推动依赖审计、最小信任等安全规范落地；下一次警报大概率会在我们以为“最熟悉、最安全”的依赖链路上响起，能否提前听见，将取决于这些观察维度能否尽快从教训变成常态。
加入我们的社区，一起来讨论，一起变得更强吧！
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
