Binance has disclosed a security incident with an estimated impact of approximately $6.3 billion after unauthorized transactions moved assets out of its wallets on October 29–30, 2026. Its preliminary investigation points to a potentially compromised DevOps engineer’s laptop, which allowed an attacker to access a service container and submit unauthorized withdrawals. Binance says it has found no evidence that wallet private keys were leaked. That distinction is central to understanding the incident: an attacker may gain the ability to obtain malicious signatures without extracting the underlying keys.
This article reflects information available on October 30, 2026. The investigation remains preliminary. Binance’s disclosures, blockchain intelligence findings, and technical interpretation should be read separately: a transaction can establish what happened on-chain, but it cannot reveal exactly how an engineer’s computer or an internal service was compromised.
The incident began on October 29 in UTC, although it was already October 30 in India. TRM Labs estimates that approximately $6.36 billion moved across ten blockchains, with most of the outflows occurring within about 20 minutes beginning around 20:05 UTC, or 1:35 a.m. IST. Its assessment points to compromised hot-wallet signing infrastructure. On Ethereum, the attacker used EIP-7702 delegation; on other networks, wallets made ordinary signed transfers.
Early headlines cited smaller totals because investigators were still identifying affected wallets and networks. Those preliminary estimates should not be treated as separate losses and added together. Binance’s approximately $6.3 billion figure is its stated total impact, while investigators’ estimates reflect their own coverage, valuation methods, and observation times.
The available chronology shows several stages rather than one isolated withdrawal. Bitquery’s reconstruction identifies these milestones:
- October 29, approximately 20:04 UTC: the earliest outflows in its reconstruction occurred on the XRP Ledger.
- 20:20:59 UTC: an Ethereum transaction submitted 50 EIP-7702 authorizations associated with Binance 14.
- 20:24:23 UTC: the main Ethereum sweep moved approximately 167,464 ETH, 1.6 billion USDT, and numerous other tokens.
- October 30, 00:10 UTC: Binance revoked the Ethereum delegation.
- 00:18 UTC: Arbitrum’s Security Council intervened to secure affected assets.
These timestamps describe different events: initial outflows, wallet delegation, asset transfers, and containment. They should not be compressed into a claim that the entire incident began and ended with the main Ethereum transaction.
The suspected laptop compromise is the most important unresolved part of the story. Binance has not yet published a complete forensic account explaining the initial infection method, credentials or sessions exposed, permissions available to the compromised device, or the exact route into the withdrawal service. Claims that a particular phishing message, malicious package, browser extension, or remote-access tool caused the breach would therefore go beyond its current disclosure.
From a security architecture perspective, the preliminary account suggests a possible progression from an employee endpoint into a privileged internal service and then into a signing workflow. This is an interpretation of Binance’s statement, not a confirmed reconstruction of every intermediate step.
A signing system can protect private keys from extraction while still producing signatures for requests that should have been rejected. For example, a compromised caller might retain a valid session, impersonate an authorized workload, or submit requests through an overly permissive internal interface. These are possible failure modes to investigate, not established facts about Binance’s implementation.
The critical question is therefore broader than whether a private key escaped. Investigators need to establish what the signing system was asked to authorize, why it accepted those requests, and which controls were supposed to distinguish a legitimate withdrawal from an attacker’s instruction.
On Ethereum, the reported use of EIP-7702 adds another layer. EIP-7702 allows an externally owned account to authorize execution of code located at another address. The wallet retains its address and balances, but calls to it can execute the delegated code in that wallet’s context. Such authorization changes the wallet’s capabilities and can persist until replaced or cleared. It deserves the same scrutiny as a change to wallet control.
Crystal Intelligence reports that the attacker installed delegation on Binance 14 using a transaction containing 50 pre-signed authorizations covering consecutive nonces. A nonce is an account’s transaction counter. The reported pattern is consistent with attempting to accommodate a busy wallet whose nonce was changing as other transactions were processed. Crystal interprets the evidence as pointing toward compromised signing access. The signatures alone, however, cannot conclusively distinguish signing-service abuse from possession of a private key.
The significance is that a valid signature can authorize a dangerous change. Blockchain validation establishes that an authorization satisfies protocol rules; it does not establish that the exchange intended to approve it. EIP-7702’s own specification warns that delegated code has extensive access to the authorizing account. Nothing in the evidence cited here establishes a flaw in Ethereum’s signature verification or consensus rules.
Several addresses are important to the public investigation. The following are selected addresses identified in Bitquery’s published reconstruction, rather than a complete list of every affected wallet or downstream recipient:
| Reported role | Network | Address |
|---|---|---|
| Binance 14, affected wallet | Ethereum | 0x28c6c06298d514db089934071355e5743bf21d60 |
| Binance 16, affected wallet | Ethereum | 0xdfd5293d8e347dfe59e90efd55b2956a1343963d |
| Main collection address | Ethereum | 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c |
| Delegated sweeper code | Ethereum | 0x63e842b054bd624a465454d533c33f573e9c6fae |
| Binance Bitcoin source wallet | Bitcoin | bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h |
| Initial Bitcoin recipient | Bitcoin | bc1q0mtc2f5agpkvlq6hhahmfr3hlr55kyfjhl2mnm |
| Initial TRON recipient | TRON | TG5iBMQPrDzJJAUM8GMVBf1hRaJ1wvzsGi |
| Reported Solana recipient | Solana | AffzFDKZbyMiU11zmVBoAqD25ugpr7xoWWyRyGigBEaU |
The Ethereum delegation transaction was 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b. The main sweep transaction was 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3. These identifiers come from the published investigation; this article does not claim an independent replay of every transaction.
Fund recovery became a race between asset movement and intervention. TRM reported approximately $2.67 billion in stablecoins frozen by issuers and additional intervention on Arbitrum involving 8,426 ETH and 74.6 million ARB, bringing its identified frozen or secured total to roughly $2.7 billion. Binance separately reported approximately $3 billion frozen. These figures represent different reporting snapshots and should not be added together.
Freezing assets is also different from returning them. A freeze restricts movement through an issuer’s controls or another intervention mechanism. Recovery requires additional steps before assets are restored to the victim’s control. Consequently, subtracting the frozen amount from the headline impact does not produce a reliable final loss figure.
The attacker also reportedly used lending infrastructure. Crystal identified 60 million USDT deposited into Aave to borrow ETH. This illustrates why freezing a stolen stablecoin balance may not immobilize all value derived from it: a borrower can receive a different asset before the collateral is restricted. The eventual consequences depend on the position, collateral treatment, and subsequent transactions.
Attribution remains another area requiring precise language. TRM Labs attributes the operation to TraderTraitor, a North Korean hacking unit, with high confidence based on its on-chain and off-chain intelligence. That is TRM’s attribution assessment. Binance’s announcement cited here does not name the perpetrator. An address cluster can demonstrate financial connections, but identifying the people or organization controlling it requires evidence beyond a list of transactions.
Binance says it will cover losses using its SAFU fund and company funds and publish updated proof of reserves after remediation. Its updated announcement says withdrawals were temporarily suspended during security checks and clarifies that deposits remained operational. These statements describe Binance’s response and commitments; they do not establish that all recovery work is complete.
For exchanges and custody providers, the incident raises practical questions about how much authority an employee device can reach and how independently a signer validates requests. Protecting a key is only one part of protecting assets. The system must also enforce what may be signed, for which destination, under which transaction type, and within what limits.
Stay safe. Secure your smart contracts before you become the next victim. Connect with us at https://safeedges.in/contact.
Add the Bastion Security extension to your coding environment to help detect private key exposure and credential leaks. All analysis runs locally, keeping your sensitive data on your machine.