币安 2026年10月安全事件 给每一个持有用户资金的组织提出了一个运营层面的问题：当一笔有效签名赋予攻击者钱包权限时，你的安全控制能否识别出来？如果组织只监控转账和所有权变更，就可能直到资产被转移才发现钱包权限已经发生变化。
币安 初步更新 称，一台被入侵的DevOps笔记本电脑使攻击者得以访问某个服务容器并提交未经授权的提现。其 第二次更新 报告了更多入侵情况，但没有证据表明钱包私钥已经泄露。在 11月3日的报告中，币安描述了一次范围更广的攻击，涉及社会工程、滥用内部AI工具、窃取凭据以及对钱包签名服务的未经授权访问。尽管如此，攻击者仍获得了有效签名，这揭示了一个重大风险：一台拥有请求签名权限的被入侵服务器，可以在不提取受保护密钥的情况下滥用该密钥。
攻击者利用了一项 EIP-7702 委托，该委托允许钱包签署一条长期有效的指令：“当我的账户被调用时，使用这段代码。”以太坊会一直保留该指令，直到使用钱包密钥对其进行更改或清除。这使得 反复转账成为可能，包括首次盗取之后新存入的资金，而无需币安再次签名。其他币安钱包则通过普通的签名转账被清空。
交易执行与监控系统必须跟上以太坊的发展。EIP-7702将委托授权置于普通calldata之外。会话密钥、恢复路径、授权模块、Safe模块以及 ERC-4337 UserOperations 都增加了执行路径，签名策略和监控系统必须理解这些路径。未更新的系统可能漏掉恶意权限变更和资产转移，使钱包暴露于风险之中。团队必须更新检测规则，并测试这些攻击路径是否已被覆盖。
如果你负责钱包基础设施的安全，请从我们的检查清单开始。
强化钱包安全的四个步骤
以下四项建议针对此次攻击暴露出的风险。我们还提供了测试方法，帮助你验证这些安全控制是否有效。
1. 减少对签名基础设施的访问
记录每一个可以请求钱包签名的服务和API、谁可以调用它，以及它可以授权什么，包括转账、委托和任意数据。每当受支持链上的钱包功能发生变化时，都要审查这份清单。将签名基础设施与日常业务系统分离，并通过独立系统核验交易详情。使用我们的 TRAIL方法 来追踪一台被入侵的笔记本电脑或服务器如何能够触及签名环节。
验证结果：
- 对于每一条已识别的入侵路径，使用被入侵系统可用的访问权限和凭据尝试执行未经批准的操作。确认预期应阻止该操作的控制措施，并保留未产生可用签名的证据。
2. 将委托视为管理权限
配置签名服务以识别会更改账户权限的请求。对于不需要委托的托管外部拥有账户（EOA），拒绝 EIP-7702 授权，并确保通用摘要签名API无法绕过该限制。在确实需要委托的情况下，分别批准授权账户、委托地址和代码、链以及nonce。在评估执行之前，模拟必须应用拟议的委托，并在检查即时余额变化的同时，检查权限和未来执行权限的变化。
验证结果：
对于已禁用委托的账户，通过专用和通用签名接口提交的委托请求均被拒绝。
更改已批准的账户、委托方、链或nonce需要重新审批。即使交易没有立即转移资产，模拟也会暴露新增的权限。
3. 即使签名被入侵也要限制损害
即使在委托之后，原始EOA密钥仍然可以转移资金或更改委托方。这意味着如果该密钥被入侵，攻击者可以绕过委托方执行的限制。应使用运营密钥无法更改的独立托管控制来保护这些资产。我们的 冷存储指南 描述了独立执行的限制、对敏感操作进行监控的延迟，以及独立的配置权限。
验证结果：
将运营密钥视为已被入侵，并尝试直接转账、替换委托方和更改策略。确认这些路径无法绕过所声称的保护措施，包括缩短或取消延迟。
针对恶意提现演练事件响应。记录告警和遏制时间，并证明响应人员能够在执行前取消或遏制该提现。确认被阻止的提现随后无法执行。
4. 检测钱包权限变更
将每个钱包映射到它所控制的资产和合约，包括不持有资金的钱包。告警应识别受影响的系统和权限（例如，某个能够升级有资金金库的账户上出现了未经批准的委托）。将直接调用、模块执行和 ERC-4337操作 归因到其授权路径。
验证结果：
测试各种委托场景、混合授权元组、多签模块执行，以及成功捆绑包中失败的UserOperations。
监控应按顺序重建权限变更和资产转移，识别受影响的系统，并区分检测与在资金转移前阻止执行的控制措施。
让签名基础设施成为一项持续的责任
如果你的组织运行钱包或签名服务，请重新审视它们的安全方式。测试你的签名策略是否考虑了EIP-7702和ERC-4337，独立防护措施在攻击者获得签名访问权限时是否仍然有效，以及你的监控是否能捕捉到账户和权限的变更。
指定某人负责这项审查，并将其纳入定期日程。每当你更改所支持的协议、所使用的钱包或签名服务时，都要重新运行这项审查。