# Binance: $6.34 billion affected without a confirmed private-key leak

> From a fake job interview to a wallet signing service and persistent EIP-7702 delegation: the technical chain reported by Binance and its limits.

Published: 2026-11-04  
Canonical: https://rootzero.eu/en/research/binance-signature-portefeuille-eip7702-2026/

**Attack: 29 October 2026. Initial Binance report: 3 November. Analysis written on 4 November.** [Binance](https://www.binance.com/fr-AF/blog/community/3229153443759566763) estimates that approximately **$6.34 billion in assets were affected**, with **$2.85 billion frozen or intercepted** by the time of its first report. Those figures are preliminary. The technical point is that an attacker gained unauthorized access to an **internal wallet signing service**. Transactions could therefore bear valid cryptographic signatures without a single private key having been publicly exposed or necessarily copied.

Binance describes an ongoing investigation and plans independent review. The incident report establishes a sequence of access; the exact policy and requests inside the signing service remain private.

## From an engineer's laptop to a signing service

In September, a software engineer was drawn into a fake recruitment process. A supposed interview exercise required downloading a repository to a work computer, where installation ran malicious code. Binance describes replacement of a legitimate `pyenv` component. On 20 October, the attackers used that host and an internal AI tool to reach other wallet engineers. They found a container deployment token on a DevOps engineer's machine. On 29 October, they reached a third engineer's machine, used the token to deploy a container and ran a malicious script. These steps are described in [Binance's initial timeline](https://www.binance.com/fr-AF/blog/community/3229153443759566763).

Binance also reports a separate June attempt involving a tampered Homebrew installer. The company says it detected that attempt, replaced the device and rotated credentials; it believes the attacker had nevertheless learned the engineer's role. That does not establish that the June device remained compromised in October.

The decisive trust boundary was **business authorization**. A signing service should sign only requests justified by an approved withdrawal workflow, with checks on destination, amount, chain and context. Binance says the intruder submitted transactions **outside the normal withdrawal process**. The report does not publish the signing policy or the exact request, so attributing the failure to a particular line of code would be speculation.

## A valid signature can authorize an unwanted transaction

A blockchain node can verify that a transaction is signed according to an account's rules. It cannot verify that Binance's fraud controls approved it. If the signing service accepts a request that bypasses business approval, the chain sees a valid transaction. An independent policy must bind every signature to an authorized operation.

Binance lists transfers including XRP, SOL, OP and BTC. Between 20:05 and 20:09 UTC, hot wallets sent 233.46 million XRP; the report also cites approximately 970,500 SOL, 44.2 million OP and 18,270 BTC. Large-transfer alerts started the response. These are [initial reported figures](https://www.binance.com/fr-AF/blog/community/3229153443759566763), not a final reconciliation.

## Why stopping withdrawals did not erase EIP-7702 delegation

[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) lets an ordinary Ethereum account authorize delegation to a contract address. A type `0x04` transaction carries an authorization tuple including a `chain_id`, code address and `nonce`. After checking the signature, the protocol places a delegation indicator, `0xef0100 || address`, on the authorizing account. Later calls run the designated code **in that account's context**. This on-chain state persists after an off-chain withdrawal service stops.

Binance says the attackers made accounts authorize code they controlled after a series of 50 transactions involving nonces and delegation. It describes partial execution rights. The EIP itself does not impose a spending limit; any narrower permission would depend on the delegated code. Without the code and transaction-level analysis, the precise effective authority is unknown. Binance says it signed a further authorization to the zero address to clear the delegation at 00:10 UTC on 30 October.

The wallet used **multiparty computation**, so no single immediately usable private key was available to produce that revocation. MPC splits signing authority, but an emergency response can require coordination while the harmful on-chain permission remains active. Binance says a previously broadcast transfer of 2,961.9 ETH finalized at 23:56 UTC during the response. Suspending an application and clearing pending blockchain transactions are different operations.

## How the chain could have been found earlier

Each step offers a different signal: an interview repository on a work device, a replaced local binary, unusual access to the internal AI tool, use of a deployment token outside its usual context, a new container near wallet infrastructure, and finally a signing request with no matching approved withdrawal. The strongest control connects a **signature to its business origin** and rejects any request without a justified destination, amount and chain. On Ethereum, monitoring EIP-7702 authorizations and delegated code is necessary alongside withdrawal counters.

Incident response must inspect both the compromised systems and the state of **each chain**: persistent authorizations and transactions already broadcast. Binance says it rebuilt affected wallet systems and the AI tool, replaced devices and tightened signing policies. It attributes the operation to North Korean actors based on FBI communication; that attribution does not change the mechanics in its initial report.

The distinction between a secret and permission to use it also appears in the [eMudhra incident](/en/research/emudhra-cle-privee-quatre/), where the keys themselves were weak. Binance instead describes access to the service that uses them. For deployment tokens and software trust boundaries, compare the [compromised LiteLLM release](/en/research/litellm-release-empoisonnee-2026/), without assuming a shared cause.

**Primary sources:** [Binance initial incident report](https://www.binance.com/fr-AF/blog/community/3229153443759566763), [EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702).