Binance’s October 2026 security incident raises an operational question for every organization holding user funds: Can your security controls recognize when a valid signature grants an attacker wallet authority? If an organization only monitors transfers and ownership changes, it may miss the shift in wallet authority until assets move.
Binance’s initial update about the incident suggested that a compromised DevOps laptop allowed an attacker to access a service container and submit unauthorized withdrawals. Its second update reported additional breaches but no evidence that wallet private keys had leaked. In its November 3 report, Binance described a broader attack involving social engineering, misuse of an internal AI tool, stolen credentials, and unauthorized access to its wallet-signing service. The attacker nevertheless obtained valid signatures, illustrating a major risk: a compromised server with permission to request signatures can misuse a protected key without extracting it.
The attacker used an EIP-7702 delegation that allows a wallet to sign a standing instruction: “Use this code when my account is called.” Ethereum keeps that instruction in place until it is changed or cleared using the wallet’s key. That enabled repeated transfers, including funds deposited after the first theft, without further signatures from Binance. Other Binance wallets were drained through ordinary signed transfers.
Transaction execution and monitoring systems must keep pace with Ethereum. EIP-7702 places delegation authorizations outside ordinary calldata. Session keys, recovery paths, authorization modules, Safe modules, and ERC-4337 UserOperations all add execution paths that signing policies and monitors must understand. Systems that have not been updated can miss malicious authority changes and asset movements, leaving wallets exposed. Teams must update their detection rules and test that these attack paths are covered.
If you’re responsible for securing wallet infrastructure, start with our checklist.
Four steps to strengthen wallet security
These four recommendations address the risks exposed by the attack. We also provide tests to help you verify that these security controls work.
1. Reduce access to signing infrastructure
Document every service and API that can request wallet signatures, who can call it, and what it can authorize, including transfers, delegation, and arbitrary data. Review this inventory whenever wallet functionality changes on supported chains. Separate signing infrastructure from everyday business systems and verify transaction details through an independent system. Use our TRAIL method to trace how a compromised laptop or server could reach signing.
Verify the result:
- For each identified compromise path, use the access and credentials available to the compromised system to attempt an unapproved action. Identify the control expected to block it and retain evidence that no usable signature was produced.
2. Treat delegation as an administrative privilege
Configure signing services to recognize requests that change account authority. Reject EIP-7702 authorizations for custody externally owned accounts (EOAs) that do not need delegation, and ensure generic digest-signing APIs cannot bypass that restriction. Where delegation is required, separately approve the authorizing account, delegate address and code, chain, and nonce. Before evaluating execution, simulations must apply the proposed delegation and inspect changes to permissions and future execution authority alongside immediate balance changes.
Verify the result:
Delegation requests for accounts with delegation disabled are rejected through both dedicated and generic signing interfaces.
Changing an approved account, delegate, chain, or nonce requires renewed approval. Simulations expose added authority even when the transaction moves no assets immediately.
3. Limit damage even if signing is compromised
Even after delegation, the original EOA key can still transfer funds or change the delegate. This means that if the key is compromised, an attacker can bypass limits enforced by the delegate. Protect those assets with separate custody controls that the operational key cannot change. Our cold-storage guidance describes independently enforced limits, monitored delays on sensitive actions, and a separate configuration authority.
Verify the result:
Treat the operational key as compromised and attempt direct transfers, delegate replacement, and policy changes. Confirm these paths cannot bypass the claimed protections, including shortening or removing delays.
Exercise incident response against a malicious withdrawal. Record alert and containment times, and demonstrate that responders can cancel or contain the withdrawal before execution. Confirm that the blocked withdrawal cannot subsequently execute.
4. Detect changes in wallet authority
Map each wallet to the assets and contracts it controls, including wallets that hold no funds.
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: