Binance lost roughly $6.34 billion in virtual assets on October 29. That number is large enough to make people stop reading the sentence after it. Keep reading. The part that should bother anyone who has ever had to build an emergency stop is this: Binance suspended withdrawals, and the attacker kept moving assets.
The company’s preliminary report says attackers obtained unauthorized access to an internal wallet signing service. They used it to initiate transactions outside the normal withdrawal process. That distinction is the entire bloody story. If your stop button is wired to the front door, it does nothing for someone already in the machine room.
The keys were not the only keys
Binance says its investigation found no evidence that wallet private keys leaked. I can believe that and still be unimpressed. A service allowed to ask a wallet to sign transactions is an authority in its own right. If an attacker can reach that service and persuade it to sign the wrong thing, the secret key can stay exactly where the diagram says it lives while the money walks out.
The reported path was ugly and familiar. In September, an engineer took a fake job interview and downloaded a malicious code repository as an interview task. Malware ran during setup. By October 20, the attackers had used that compromised computer and an internal AI tool to reach colleagues in wallet engineering. Binance says they found a container deployment token on one engineer’s machine, then used stolen credentials and another engineer’s computer on October 29 to deploy a container and trigger the attack. The report also describes an earlier tampered Homebrew download in June, but says the device was replaced and credentials rotated then. Do not flatten these into one magic laptop. Binance calls this a multi-stage campaign, and its account is still preliminary.
The fake interview is the human part. The deployment token on a workstation is the architectural part. A workstation used for browsing, interviews, and arbitrary development tasks should not be a path to production wallet signing. A container deployment permission should not become permission to move customer assets. Every boundary between those two statements is supposed to be independently hard to cross. At least one was not.
The stop button had a jurisdiction
After the initial transfers, Binance suspended normal withdrawals. Its report says the attacker had also used EIP-7702, an Ethereum mechanism that lets an account delegate execution rights to contract code. The attacker submitted 50 signing transactions to establish malicious delegations and manipulate the account nonce. Once those authorizations existed on-chain, shutting down Binance’s withdrawal service could not erase them. The company had to send additional transactions to revoke them. Its multi-party computation wallet setup also meant there was no single private key to grab for an instant revocation.
This is not an argument that EIP-7702 is broken. The feature did what signed authorization tells it to do. The failure was allowing a compromised signing path to authorize behavior that survived the company’s ordinary containment move. The blast radius crossed from an internal service into state on a public chain, where the internal kill switch had no authority.
I would want to know which signing policies allowed those authorizations, what separate approval was required for delegation transactions, and whether an emergency procedure to revoke them had ever been rehearsed. Binance says it is reviewing signing policies and hot-wallet controls. The public report does not answer those questions yet. Anyone claiming the exact missing check from outside is selling a diagram with invisible boxes.
Reimbursement is not containment
Binance says it has reserved more than enough of its own funds to cover the loss and, in its November 4 recovery update, that about 98% of the affected token assets had been replenished. Its incident report says roughly $2.85 billion had been frozen or intercepted as of November 3. Those are different measures. Replenishing customer balances is a financial response; freezing stolen assets is a recovery effort. Neither changes how the signing service was reached.
Credit where due: Binance published more of the attack path than the usual “sophisticated actor” shrug, including the delegation problem that made its first containment step insufficient. That gives other operators something useful to examine. It also gives us a sharper question than whether the private key was stolen. When your most privileged service is tricked into signing, what can it authorize, and which of those authorizations still work after you hit stop?
If you run any signing system, payment rail, or privileged deployment pipeline, draw the path from a developer laptop to the irreversible action. Then draw the path your emergency stop actually cuts. If the lines do not meet, the attacker will find the gap before your incident review does.