Polkadot 警告 Fearless Wallet 扩展遭入侵:私钥泄露一年半,8 名用户被盗 17,286 枚 DOT

Polkadot 警告 Fearless Wallet 扩展遭入侵:私钥泄露一年半,8 名用户被盗 17,286 枚 DOT

Aiying 艾盈是一家专注于传统金融及Web3的合规咨询服务机构,本文为团队原创,转载需授权。

2026 年 10 月 22 日,Polkadot 发布安全警告称,第三方钱包 Fearless Wallet 的浏览器扩展程序遭入侵,自 2025 年 2 月起间歇性向攻击者泄露用户私钥,跨度长达一年半。据 Polkadot 社区基金会公告,恶意代码会在用户解锁钱包时,将私钥发送至攻击者控制的服务器;目前已有 8 名用户报告疑似相关的未授权交易,涉及 17,286 枚 DOT。Polkadot 敦促所有曾使用该扩展程序的用户立即通过其他钱包创建全新密钥对并转移资产——仅修改密码或更换钱包软件,无法消除已被泄露私钥带来的风险。

5 点摘要

  1. 10 月 22 日 Polkadot 发布警告,第三方钱包 Fearless Wallet 浏览器扩展遭入侵,自 2025 年 2 月起泄露用户私钥长达一年半。
  2. 恶意代码在用户解锁钱包时把私钥发往攻击者服务器,已致 8 名用户疑似被盗 17,286 枚 DOT。
  3. Fearless Wallet 由独立团队开发,并非 Polkadot 官方钱包,暴露了第三方扩展接入公链生态的信任边界问题。
  4. Polkadot 要求用户用其他钱包创建全新密钥对并转移资产,改密码或换软件无法根除已泄露的私钥风险。
  5. 这是继 Solana Slope、Ledger Connect Kit 之后又一起钱包供应链/私钥泄露事件,凸显非托管钱包的安全责任与披露机制短板。

一、事件脉络:一次持续一年半的「静默泄露」

与典型的「一次入侵、瞬间盗币」不同,本案最令人不安之处在于其隐蔽性与持续性。恶意代码并非立即转走资产,而是「在用户解锁钱包时」将私钥静默上传至攻击者服务器——这意味着在长达 18 个月的时间里,攻击者始终握有受感染用户的私钥副本,只需等待合适时机即可对资产发动攻击。8 名用户报告的被盗金额(17,286 枚 DOT)可能只是冰山一角,更多未触发交易、或资产早已被分批转移的用户,风险仍未出清。

另一个值得注意的治理细节是:Fearless Wallet 由独立团队开发,并非 Polkadot 官方钱包。第三方扩展通过「浏览器扩展商店」这一分发渠道接入公链生态,用户往往默认「能装上、能转账」即等于安全可信,却忽略了扩展开发者与底层协议团队之间的责任并非一体。

二、非托管钱包的私钥安全:责任边界在哪

非托管钱包的核心承诺是「私钥由用户自持,平台不接触资金」,但这并不意味着钱包开发者在安全事件中可以全身而退。私钥安全实际上横跨三层的责任:其一,密钥生成与存储的实现质量(是否使用安全的随机数、是否本地加密保存);其二,软件分发的供应链完整性(扩展更新是否被篡改、是否经过代码签名);其三,事件发生后的披露与止损义务(能否及时发现、及时通知用户、提供转移指引)。

本案中,恶意代码通过浏览器扩展的自动更新机制进入用户设备,恰恰击中了「供应链完整性」这一层。对钱包团队而言,若最终被证实其在扩展发布流程、第三方依赖管理或代码审计上存在过失,用户依侵权或合同之诉主张赔偿并非没有空间;而若属上游依赖遭劫持(如 Ledger Connect Kit 事件中 npm 包被注入恶意代码),责任认定则会转向更复杂的供应链链条。

三、浏览器扩展与供应链攻击的合规警示

本案并非孤例。2022 年 Solana 生态 Slope 钱包因将用户助记词明文上传至第三方日志服务,导致逾 8000 个钱包被盗;2023 年 Ledger Connect Kit 因 npm 库被劫持注入恶意代码,波及多个主流 DApp 前端。三起事件的共同点在于:攻击对象都不是链上协议本身,而是「用户与链之间的软件中介」——钱包扩展、SDK、依赖库。

这一趋势对机构的合规含义在于:凡向用户提供钱包、SDK 或前端接入能力的机构,其风险矩阵不应只覆盖链上智能合约与私钥托管,还必须覆盖软件供应链、第三方依赖、扩展商店发布流程与事件响应预案。监管者虽尚未对非托管钱包施加牌照要求(欧盟 MiCA 明确将去中心化、非托管服务排除在 CASP 定义之外),但消费者保护与网络安全维度的执法,已越来越多地指向「软件交付环节的过失」。

四、对机构与用户的实务建议

对使用或集成第三方钱包的机构而言,有三点应即刻落实:第一,建立「密钥生命周期」审查机制,凡面向用户的软件,均要求第三方钱包或 SDK 提供商出具安全审计与供应链完整性证明;第二,将浏览器扩展、移动端钱包等「非托管载体」纳入供应商尽调与持续监测范围,而非仅关注托管方资质;第三,在自身产品中内置异常预警与快速迁移通道,确保事件发生后能在第一时间通知并引导用户转移资产。

对普通用户而言,最关键的教训仍是那句老话:非托管钱包的「安全」高度依赖软件供应链的可信度。仅修改密码、更换钱包软件,无法消除已被泄露私钥的风险——唯有立即创建全新密钥对、并将资产转移至可信的新地址,才是止损的唯一正解。

发表回复