TopsTip
一名用户可以认真抄下 12 个助记词，把纸条锁进抽屉，甚至再把这组词导入硬件钱包；但如果这些词最初由一个可预测的随机数函数生成，所有这些保护都没有改变最关键的事实：攻击者可能已经能算出同一组词。
区块链安全公司 Coinspect 8 月披露，“Ill Bloom”钱包盗窃事件的根因已被定位到 JavaScript 加密库 CryptoJS 的 CryptoJS.lib.WordArray.random()。该函数在旧版本中并非密码学安全随机数生成器，却被至少五款钱包应用用于生成 BIP39 恢复短语。Coinspect 对两轮链上盗窃的测算显示，截至 2026 年 7 月 13 日，已识别损失下限为 5,690,922 美元。
这次更新比 7 月的初步预警更具体：研究人员不仅知道“某些钱包随机性不足”，还找到了共同的代码来源、缩小后的搜索空间，并公开了五款确认使用该路径的应用。对用户来说，这把一个模糊风险变成了可执行的迁移通知；对开发团队来说，它也是一次关于开源依赖、密码学 API 和长期密钥轮换的事故复盘。
五款应用被确认，受影响版本并不都已公开
据 Coinspect 向 The Hacker News 提供的调查结果，确认使用该弱随机数函数生成恢复短语的应用包括 RRWallet、Bexo Wallet、NanChat、Bitcoin Libre 和 Milo。这五款应用就是 Coinspect 在 7 月首次披露时暂未点名的五个钱包实现。
- RRWallet：Coinspect 称项目已经停止运营，没有修复版本。
- Bexo Wallet：Coinspect 称问题已在 20.1.0 修复，但截至 8 月 6 日，更新后的构建尚未上传应用商店；The Hacker News 当日看到的 iPhone 当前版本仍为 18.3.5。
- NanChat：项目方独立确认 1.3.0 之前的版本受影响，并在 1.3.0 中加入生成新助记词和迁移资产的工具。
- Bitcoin Libre：Coinspect 称该问题已在 2024 年 7 月发布的版本 4 中修复。
- Milo：Coinspect 称项目已经停止运营，没有修复版本。
公开资料尚未给出 RRWallet、Bexo、Bitcoin Libre 和 Milo 的完整受影响版本范围。Coinspect 也明确表示，五款并不一定是全部：一些旧应用或浏览器扩展已经从商店下架，研究人员无法再取得历史安装包；另一些项目可能已经替换代码，却没有保留可供检查的旧版本。
因此，名单适合确认风险，却不能用来证明名单之外一定安全。Coinspect 的公开地址检查器也采用相同边界：命中意味着同一助记词控制的资产可能处于即时风险；未命中只代表地址不在当前公开数据集中，不等于钱包通过了安全审计。
12 个单词没有变少，真正缩水的是背后的可能性
BIP39 助记词可以理解为随机比特的可读编码。正常情况下，128 位或 256 位熵对应的可能组合极其庞大，攻击者不可能靠逐个尝试找到正确答案。词表和校验规则负责把这些随机比特转换成方便备份的单词，但它们不会凭空创造随机性。
CryptoJS 旧实现的问题就在起点。GitHub 于 8 月 5 日发布的官方安全公告 GHSA-rg76-677x-56q9 将其评级为 Critical，CVSS 分数为 9.0。公告显示，名义上的 128 位与 256 位随机请求，实际可搜索空间约只有 2^39 和 2^47。这个数量对个人仍然巨大，对能够并行计算的攻击者却已经进入可以枚举的范围。
该实现使用一种 Multiply-With-Carry 伪随机生成器，并由 Math.random() 提供种子。它在 2014 年 6 月进入 CryptoJS 3.1.2-4；3.2.0 和 3.2.1 一度改用平台原生的密码学随机源，但 3.3.0 因兼容性考虑恢复了弱实现。直到 2020 年 2 月发布 4.0.0，原生密码学随机性才被永久恢复。
这段版本历史有一个反常识后果：项目如果只在 3.x 分支内“升级到更新版本”，可能从使用安全随机源的 3.2.1 回到含弱生成器的 3.3.0。安全公告把所有低于 4.0.0 的版本列为受影响范围，同时提醒，安装旧版 CryptoJS 本身并不等于可被利用；应用必须实际调用 WordArray.random() 生成助记词、密钥或其他安全敏感值，漏洞链条才成立。
攻击者不需要入侵手机，只需重建候选钥匙
Coinspect 复现的攻击链很直接：重写旧随机数函数，枚举它能产生的输出，把候选输出转换为有效 BIP39 助记词，再按常见派生路径计算私钥与区块链地址，最后把这些地址同公开链上数据比对。找到有余额的地址，就等于找到了一把可尝试的钥匙。
这也解释了为什么盗窃能跨链发生。同一组助记词可以派生 Bitcoin、Ethereum、Tron、Polygon、Rootstock 等网络上的地址。攻击者一旦恢复种子，不必分别破解每条链；他只需检查这组种子在不同网络上控制了什么。
Coinspect 的链上分析记录了两轮主要事件。5 月 27 日，431 个账户被集中清空，损失约 314 万美元。第二轮从 5 月 30 日持续至 7 月 13 日，涉及与 522 组种子相关的地址，损失约 255 万美元；其中 7 月 4 日一个 Tron 账户单独损失约 218 万 USDT。两轮合计 5,690,922 美元，研究人员强调这是已测量的下限，而不是整个事件的最终总额。
调查共追踪到 2,114 组已识别种子及其在 Bitcoin、Ethereum、Tron、Rootstock 和 Polygon 上的关联地址。链上记录能证明资产如何移动，却不能自动证明每一笔异常转账的幕后身份；Coinspect 根据批量执行、共同收款路径和跨链活动，将这些移动判断为协调盗窃。文章因此采用“研究人员测算”和“已识别损失下限”，不把尚未完成的归因写成司法结论。
升级应用修不了已经出生的旧助记词
普通软件漏洞往往可以通过更新关闭入口，Ill Bloom 更麻烦。弱随机性在钱包创建的一刻已经写进助记词。后续使用哈希函数、PBKDF2 或其他密钥派生函数，只会对原始输入继续计算，无法补回从未存在过的熵。
同样，把旧助记词导入最新版应用或硬件钱包，也只是把同一把可猜测的钥匙换了一个保管盒。GitHub 公告建议，受影响用户必须从可信来源生成一组全新的恢复短语，再把资产转移到新地址；不能继续导入旧短语。Coinspect 当前证据显示，由硬件钱包自身生成的种子以及大多数现行主流软件钱包不受影响。
用户可以在 Ill Bloom 官方检查器中输入公开钱包地址核对已知数据集。检查器不需要，也绝不应该接收助记词、私钥、密码、签名或钱包备份。围绕安全事件出现的“资产救援”服务很容易成为第二轮诈骗：任何要求提交秘密信息或先转账的页面，都不应被信任。
这起事件暴露了钱包行业的依赖审计缺口
从产品角度看，五款钱包未必各自独立发明了同一种错误。Coinspect 指出，ferrumnet/bip39 这个面向 React Native 的 BIP39 分支，是弱函数进入钱包软件的一条路径，但不是唯一渠道。上游依赖、分支代码和复制粘贴的实现，让一个 2014 年的决定跨越多个项目存活多年。
我的判断是，真正的行业问题并非“JavaScript 不适合加密”，而是开发团队把“库名里有 crypto”误当成安全保证。密码学 API 的名称、输出长度和单元测试都可能看起来正常；只有审计熵的来源、调用路径和版本变更，才能确认生成的秘密是否真的不可预测。
对钱包团队和其他处理长期凭证的产品经理，这次事故给出三项具体检查：依赖清单里是否存在 CryptoJS 4.0.0 之前的版本；业务是否真的调用过 WordArray.random() 生成安全敏感值；如果调用过，能否定位受影响的应用版本、创建时间和用户，并要求轮换长期秘密。只升级依赖而不通知旧用户，会让新安装变安全，却把历史钱包继续留在攻击者的扫描列表里。
接下来需要观察的信号也很明确：Bexo 20.1.0 是否真正进入应用商店；其余项目是否补充完整版本范围和迁移公告；Coinspect 是否找到更多钱包实现；以及链上是否出现新的自动化清空。对可能使用过这些应用的用户而言，等待名单变完整不是一个安全策略。关键问题只有一个：你的助记词是否由受影响路径生成。如果答案是“可能”，新建钱包并迁移，比继续猜测更可靠。
资料来源
- The Hacker News：CryptoJS 弱随机数与五款钱包调查
- GitHub Security Advisory：GHSA-rg76-677x-56q9
- Coinspect：Ill Bloom 调查概览
- Ill Bloom：CryptoJS 漏洞技术分析
- Ill Bloom 官方公开地址检查器
