Trail of Bits: after the Binance hack, audit what your signing systems can approve

A November 6, 2026 post from Trail of Bits, authored by Tarun Bansal, Jaime Iglesias and Anish Naik, reframes the October Binance incident around a specific control gap: valid signatures from a compromised signing service, combined with an EIP-7702 delegation, can hand an attacker ongoing authority over a wallet without ever exposing the key. The post is titled "After Binance, check what your signing systems can approve".

Why this clears the beat bar: it is a concrete, prescriptive audit checklist pegged to the biggest exchange exploit of the cycle, written by one of the firms doing primary custody-system threat modelling. The post is advisory, not a tool release, so what follows is a summary of its claims and recommendations.

What Trail of Bits says the Binance hack actually revealed

The post works off the exchange's own November 3 internal report, not press summaries. Per that report, which Trail of Bits cites:

• Social engineering + misuse of an internal AI tool gave the attacker stolen developer credentials.
• With those credentials, the attacker reached the wallet-signing service.
• The attacker never extracted a private key. Instead, they obtained valid signatures from the signing service for transactions of their choosing.
• One of those signatures authorized an EIP-7702 delegation. Under EIP-7702, a signature of an authorization tuple lets an attacker-controlled contract be installed as the delegated code of a normal EOA.
• Once delegated, the attacker-controlled code transferred funds including funds deposited later, without further signatures from the real signing service. Other, non-delegated wallets were drained through ordinary signed transfers.

The key sentence in the post: "A compromised server with permission to request signatures can misuse a protected key without extracting it."

The four recommendations

1. Reduce access to signing infrastructure. Inventory every service that can request a signature and every principal that can call it. Separate signing systems from day-to-day business systems. Verify transaction details through an independent system before signing.
2. Treat delegation as an administrative privilege. For custody EOAs that do not need delegation, reject EIP-7702 authorizations outright — including through any generic digest-signing API. Where delegation is needed, approve the (account, delegate address, delegate code, chain, nonce) tuple separately. Transaction simulations should show changes to future execution authority, not just immediate balance deltas.
3. Limit damage even when signing is compromised. Keep separate custody controls that the operational key cannot change. The original EOA key can still transfer funds or replace a delegate, so test that an attacker holding the operational key cannot bypass delays or withdrawal limits.
4. Detect changes in wallet authority. Map each wallet to the assets and contracts it can control — including empty wallets that are still delegated or set as a module. Attribute direct calls, module execution, and ERC-4337 UserOperations to their authorization paths. Test mixed authorization tuples, multisig-module execution, and failed UserOperations inside successful bundles.

Prior art the post leans on

• Trail of Bits' TRAIL threat-modeling method, for tracing how a compromised dev laptop or build server can reach the signer.
• Trail of Bits' safer cold-storage guidance for Ethereum, for independently enforced limits and monitored withdrawal delays.
• Specs: EIP-7702 (set EOA account code) and ERC-4337 (account abstraction).

Limits

• No new open-source tool is released with the post. The deliverable is the audit checklist and a reading list.
• The post doesn't model MPC or HSM-based custody separately, though the checklist items apply directly (a threshold signer that will sign a 7702 authorization is still the same control failure).
• It assumes the Binance report is substantially accurate. If a later Binance post-mortem revises the attack path, point (4) — EIP-7702 authority capture — is the specific claim most sensitive to that revision.

What to do on Monday

1. Grep your custody stack for any API that returns a signature from a raw digest (e.g., eth_sign, personal_sign without typed-data gating). Those are the EIP-7702 ingress paths.
2. Add a rule in your signer that rejects any payload whose first byte matches the EIP-7702 SET_CODE_TX_TYPE (0x04), unless the request is approved through a separate privilege-elevated path.
3. Enumerate wallets that have ever had a delegate set. Any current delegate not in an allow-list is a live incident.
4. Simulation in your transaction policy engine should surface authority deltas, not only token-balance deltas. If it doesn't, that is the gap.

Context

The Binance incident is the first production-scale case of EIP-7702 being used as an attack primitive rather than a UX feature. Pectra shipped EIP-7702 on Ethereum mainnet in May 2026, and prior Blockchain Posts coverage has tracked the attack path (the $6.3B hack's EIP-7702/DevOps laptop vector). Trail of Bits' contribution here is to pull the lesson from one specific hack back into generic signing-service design — which is the layer that most custody shops still treat as mature.