比特币老牌钱包 Electrum 修复高危漏洞：恶意服务器可把用户资金“劫”给攻击者

比特币最老牌的轻钱包之一 Electrum 在本周末完成了一次紧急修复。一个被定级为“高危”的漏洞，允许用户所连接的 Electrum 服务器篡改尚未确认的交易，诱导用户自己签名，把原本要付给别人的比特币转给攻击者。

Electrum 开发者 SomberNight 于 10 月 24 日在 GitHub 安全公告（GHSA-6jp4-8v48-cc5v）中公开披露了此事。公告显示，受影响版本为 4.8.3 之前的所有版本；修复版本 4.8.3 于 10 月 23 日打上代码标签，10 月 24 日发布二进制文件并同步公开。公告措辞直接：“一些服务器正在野外实施这种攻击。”目前项目方收到两起用户报告，其中一起已确认造成资金损失。

对使用 Electrum 的用户而言，这意味着一次必须尽快完成的升级：如果你仍在使用 4.8.3 之前的版本，且连接的是公共服务器而非自己搭建的节点，你的下一笔付款就可能成为攻击目标。

漏洞怎么发生的：你以为在“加速”，其实在给攻击者签支票

要理解这次攻击，先要理解 Electrum 的轻客户端设计。Electrum 不下载完整的比特币区块链，而是连接第三方服务器来获取交易池（mempool）中的未确认交易、查询余额和广播交易。官方 FAQ 也明确承认：客户端对所连接主服务器的未确认交易是“被信任的”（trusted）。这本是为了在低资源占用和可用性之间做出的权衡，但攻击者恰好利用了这一信任假设。

攻击链条可以拆成四步：

第一步，用户在钱包里构造一笔正常付款交易 tx1 并点击广播。

第二步，恶意服务器把 tx1 吞掉，不让它进入比特币 P2P 网络，同时在用户钱包的历史记录里插入一笔与 tx1 冲突的假交易 tx2。

第三步，tx2 的输出地址被替换成攻击者控制的地址，手续费被设为 0，且签名本身是无效的。问题在于，Electrum 的轻客户端设计并不对服务器返回的未确认交易做签名验证，因此这笔假交易在钱包里看起来就像一笔“已经发出但卡住”的合法付款。

第四步，用户看到付款迟迟没有确认，于是手动执行 RBF 手续费加速（bump fee）。钱包会基于这笔假交易重新签名并广播，手续费提高后的版本才是第一笔真正进入比特币网络的交易——而它把钱付给了攻击者。

整个过程里，用户真正想付的那笔钱从来没有离开过本地；用户以为自己在“救活”一笔卡住的付款，实际上是在给攻击者签一张新支票。更隐蔽的是，攻击者会对假交易的输出地址做哈希碰撞（grind），让地址末尾四位与用户原本要付的目标地址完全一致。公告引用的第一份用户报告显示，真实目标地址与假地址均以“GyQ3”结尾。对于习惯只核对地址尾部的用户，这种伪装几乎可以以假乱真。

两起用户报告：一起被拦截，一起已丢钱

根据公告披露的时间线，第一起异常由用户 dannydeezy 在 10 月 11 日私下报告。该用户广播的是一笔 2-of-3 遗留 P2SH 多重签名交易，包含 31 个输入、1 个输出，使用两台 Trezor 硬件钱包签名。广播后，他发现钱包历史里显示的未确认交易指向一个陌生地址，且该交易从未传播到比特币网络，最终状态变为“Local”，因此没有造成实际损失。

这份报告的价值在于其技术细节：该用户比对了真假两笔交易的 scriptSig，发现 31 个输入的 62 个签名全部能对应真实交易、无一能对应假交易；假交易把几乎全部金额输出到那个“尾四位相同”的仿冒地址，另附一小笔金额到该钱包自己使用过的地址，所有输出加起来约等于输入总额，手续费接近于 0。

第二起报告来自用户 Raju-K12。他在 10 月 18 日私下报告称，自己对一笔被篡改的交易执行了 bump_fee，随后确认损失资金。这也是目前唯一一起确认的资金损失案例。项目方在公告中感谢了这两位用户的负责任披露。

修复方案：验签自有输入，但入账交易仍是缺口

4.8.3 版本的修复提交（commit 90fe308）关闭了主要攻击面：客户端现在会在把交易池交易加入本地历史之前，对属于钱包自己的输入（wallet.is_mine）验证加密签名。由于攻击者无法伪造这些签名，假交易再也无法被插入用户的历史记录，攻击链条在第三步就被切断。

但修复并不彻底。SomberNight 在公告中明确承认，当前验证只覆盖“钱包自有输入”的交易；对于来自外部发送方的入账交易——即没有任何输入属于用户钱包的交易——客户端仍然不做签名验证。要补上这个缺口，轻客户端需要对未确认的父交易递归验证，一直追溯到已上链的交易；而 Electrum 本身没有完整的共识引擎和脚本解释器，这在架构上并不容易实现。公告把这一点列为已知限制，并指出“还需要额外工作才能关闭”。

在升级之外，公告给出了两条临时缓解措施：一是只连接自己运行或完全信任的服务器，这类用户不受此次漏洞影响；二是如果暂时无法升级，在签署任何交易（无论是否为了加速手续费）之前，手动完整核对输出地址和金额是否与预期一致。

不是第一次：开放服务器模型的双刃剑

这并非 Electrum 第一次遭遇服务器层面的攻击。2018 年，一场攻击活动利用恶意服务器向 Electrum 用户推送虚假升级通知，诱导用户下载带后门的客户端；到 2020 年，该系列攻击据估计从 Electrum 用户手中窃取了约 2500 万美元。

这类攻击之所以反复出现，根源在于 Electrum 的开放服务器模型：任何人都可以运行一个 Electrum 服务器，而客户端默认信任所连接服务器返回的未确认交易。这种设计让轻钱包保持了低资源占用、快速同步和易用性，代价是把“服务器不作恶”写进了安全假设。一旦网络中存在愿意作恶、且能命中特定目标的服务器，轻客户端用户就会暴露在交易替换、地址劫持乃至资金被盗的风险之下。

这也是比特币轻钱包长期面临的结构性矛盾：完全验证需要运行全节点，对普通用户门槛过高；依赖第三方服务器则必须接受一定程度的信任。此次事件之后，用户至少可以通过两点降低风险：尽快升级到 4.8.3 并保持定期更新；不要只凭地址尾部做核对，务必完整比对输出地址与金额。

后续观察

此次事件再次把轻钱包的信任边界问题推到台前。短期内，两个指标值得跟踪：一是 4.8.3 的补丁采纳率，二是是否出现更多损失报告——这将决定此次攻击的实际波及范围。长期看，Electrum 是否会为入账交易引入更完整的验证机制，以及社区对“开放服务器模型”这一安全假设的重新评估，将决定这类攻击能否被根本性遏制。