Vultisig在8月更新安卓和iOS应用，修正了多方计算签名流程中的错误处理：当签名库判定参与者存在恶意行为时，应用不再自动重试，并会提示用户停用相关设备。ChainSecurity于10月21日披露的研究指出，旧流程可能让已经控制一个签名参与方的攻击者，通过反复发送恶意消息并观察错误响应，逐步恢复另一方的密钥份额，最终拼出完整私钥。
这项问题涉及ECDSA签名。它提醒用户，多设备共同签名的安全性不只取决于私钥是否分散保存，也取决于应用能否在协议发出停止信号后中止后续交互。即使失败的签名没有生成可用交易，错误响应本身仍可能泄露信息。
错误响应可能暴露内部协议种子
多方计算钱包将签名权分布在多个密钥份额之间，正常签名时，各方协作生成区块链可识别的标准签名，而无需在常规操作中重组成完整私钥。在要求两台设备都参与的配置中，若攻击者只控制其中一方，理论上仍需另一方批准才能完成签名。
ChainSecurity披露的攻击路径以其中一个参与方已遭入侵为前提。攻击者可向另一方发送多条恶意签名消息，再观察对方是否返回错误。研究人员指出，这些响应可能逐步泄露可重复使用的内部协议种子中的信息；若持续利用，攻击者可能恢复另一方的密钥份额及完整私钥。
该种子是协议内部的设置秘密。相关签名库原本假设，发生严重错误后，调用方会停止后续签名，直至轮换该种子。旧版应用没有落实这一停止条件，只向用户显示一般性失败提示，并可能继续重试。因此，问题不在于一次失败签名能否广播，而在于失败后是否仍继续与被标记的参与者交互。
8月更新识别恶意参与者并停止重试
Vultisig安卓和iOS维护者分别于8月21日合并相关代码变更，时间比10月公开披露早约两个月。旧代码会将签名失败与签名库的成功结果进行比较，却没有单独处理恶意参与者的封禁错误；签名流程最多可重试三次，用户看到的则是通用失败信息。这个重试次数并不代表恢复密钥所需的消息数量，也不能据此推断攻击需要多少次会话。
更新后的应用会在会话建立、消息处理和签名完成等阶段识别DKLS签名库的恶意参与者错误码100至109。两端都会将被标记的参与者对应到设备标识，避免该错误被自动重试机制吞掉，并向用户显示本地化警告，提醒不要继续使用相关设备。安卓版本还会跳过中继恢复流程。
这意味着应用开始区分普通签名失败与密码学库对参与者作出的恶意判定。对于临时故障，自动重试可能有助于恢复操作；但在库已要求停止交互时，继续重试则可能扩大信息暴露。
相关变更分别列于安卓PR #5658和iOS PR #5235。iOS v1.45.71的发布记录日期为8月21日，安卓v1.0.118的发布记录日期为8月25日，两者均列出相应修复。
不同金库配置的影响仍需厘清
Vultisig的产品说明区分了签名设备的控制方式：Fast Vault由用户设备持有一个份额，VultiServer持有另一个份额并参与共同签名；Secure Vault则由用户控制的两台或更多设备分担签名，不依赖VultiServer。两类方案都采用分布式签名，但运营依赖不同；一次签名会话中的两个参与方，也不必然意味着整个金库只有两个份额。
目前披露的研究和应用资料没有给出完整的受影响版本与金库配置对应表。用户因此难以仅凭现有信息判断各类配置具体受影响范围，以及更新对不同历史版本的覆盖情况。
Vultisig安全文档称，Trail of Bits于2024年审计了Silence Laboratories的DKLS23库，并表示移动端和桌面端应用审计报告将在发布后提供。ChainSecurity披露时表示，尚未审查Vultisig的修复，也未审计协议的其他部分，因此这些应用层修复不在其评估范围内。
后续仍需明确哪些已发布版本和金库配置受影响，并说明应用在自动重试及用户手动重新启动签名后，是否都能执行停止条件。此次问题的关键在于，持有人所依赖的多方隔离不仅要由签名库提出要求，也要由应用在整个签名流程中持续落实。