On October 29, 2026, attackers drained Binance hot wallets across multiple blockchains in what blockchain analytics firms call the largest crypto theft on record. Binance puts the impact at about $6.3 billion, with roughly $3 billion frozen, and says early findings point to a possibly compromised engineer's laptop, with no evidence of leaked private keys so far. Here's what happened, what's still unconfirmed, and what to check in your own environment.
What happened at Binance?
Attackers drained Binance hot wallets on several blockchains on October 29, 2026, starting around 20:05 UTC, according to TRM Labs.
How much was taken?
Binance estimates about $6.3 billion. TRM Labs puts it at $6.36 billion across ten blockchains, the largest crypto theft ever.
How did the attackers get in?
Binance's preliminary findings suggest a DevOps engineer's laptop may have been compromised, giving access to a service container that submitted unauthorized withdrawals.
Who was behind it?
Binance hasn't formally confirmed attribution. TRM Labs and Chainalysis attribute it to North Korea's TraderTraitor, and the FBI has linked the group to it.
Will customers lose money?
Binance says it will cover all losses through its SAFU fund and its own funds.
Key Takeaways
- Binance estimates the impact at about $6.3 billion and says roughly $3 billion has been frozen on-chain.
- Preliminary findings point to a possibly compromised DevOps engineer's laptop, with no evidence of a private key leak so far.
- On Ethereum, the attacker used 50 pre-signed EIP-7702 authorizations to hand a hot wallet to a sweeper contract, per TRM Labs and Blockaid.
- TRM Labs and Chainalysis attribute the theft to North Korea's TraderTraitor; Binance hasn't formally confirmed it.
- The lesson isn't about key storage. A protected key can still sign the wrong transaction, so the path to the signer needs protecting too.
- This is the biggest money-moves-through-the-signer story yet, and the same pattern hit Bybit in 2025.
Also Read: Oracle E-Business Suite RCE (CVE-2026-101767)
What Happened
TRM Labs says preparation was underway by October 28, when small Tornado Cash withdrawals funded an operator wallet. Around 20:05 UTC on October 29, five Binance XRP Ledger wallets sent 233.46 million XRP to a single attacker address. Wallets on Solana, Optimism, Bitcoin, Tron, and Ethereum followed within about 15 minutes, and a second wave hit Avalanche and Polygon at 23:05 UTC. Most of the theft unfolded in roughly 20 minutes across ten blockchains.
In a statement on October 30, Binance said it temporarily suspended deposits and withdrawals and revoked authorization for the affected addresses. Its preliminary investigation suggests the incident may have involved the compromise of a DevOps engineer's laptop, from which the attacker reached a service container and submitted unauthorized withdrawal transactions. Binance stressed it had found no evidence that any wallet's private key was leaked, and said it would cover all customer losses through its SAFU fund and its own reserves. The timing is no coincidence: the hack capped a month of record-breaking attacks and disclosures we rounded up in Black October 2026.
How the Attack Worked
TRM Labs' analysis explains the Ethereum step. EIP-7702, added in Ethereum's Pectra upgrade in May 2025, lets an ordinary wallet run smart contract code through a signed authorization. Each authorization is valid at only one transaction count, so the attacker submitted 50 in a row, all signed by a Binance hot wallet, to be sure one matched. The wallet then took orders from the attacker's sweeper contract, which drained 167,464 ETH and 63 tokens about three and a half minutes later.
TRM assesses the attacker most likely got Binance's signing system to produce valid signatures of its choosing, rather than stealing a key outright. Blockaid's CEO told Cointelegraph its preliminary view is the same: a compromise of signing infrastructure, not a leaked key. Note that not everyone agrees; Mt. Gox's former head told Reuters the attackers had probably accessed keys for at least two wallets. The root cause is still open.
Detail | Value |
|---|---|
Organization | Binance |
Date | October 29, 2026, from about 20:05 UTC |
Estimated impact | About $6.3 billion (Binance); $6.36 billion across ten blockchains (TRM Labs) |
Largest losses | ~$3.79 billion on Ethereum; 18,270 BTC; 612.7 million USDT on Tron; 233.46 million XRP (TRM Labs) |
Frozen | ~$3 billion (Binance); ~$2.7 billion counted on-chain (TRM Labs) |
Possible entry point | Possible compromise of a DevOps engineer's laptop, then a service container (Binance, preliminary) |
Private keys | No evidence of a leak so far (Binance) |
Ethereum technique | 50 pre-signed EIP-7702 authorizations delegating a hot wallet to a sweeper contract |
Attribution | Not formally confirmed by Binance; TraderTraitor (TRM Labs and Chainalysis); FBI links the group to it |
Customer losses | Binance says it will cover all losses through SAFU and its own funds |
What to Do Now
Binance hasn't published its root cause, so treat these as general checks for any organization where software can move money or assets.
- Contain a suspected engineer compromise immediately, preserving evidence. Isolate the device and revoke its tokens, SSH keys, cloud credentials, and active sessions without delay. Preserve endpoint, container, and access logs in parallel.
- Separate engineer laptops from systems that move money. Allow access to signing and payment services only from dedicated admin workstations, with MFA and just-in-time approval. Developer tools are a common way in, since malicious IDE extensions can steal secrets straight off a developer's machine.
- Enforce policy inside the signer. A signing service should refuse requests that break its rules, whoever sends them: per-transaction and daily limits, destination allow-lists, and multi-party approval for large withdrawals. Don't sign message types you don't use, such as EIP-7702 authorizations.
- Monitor signing requests, not just balances. Alert on bursts of signatures, batches of authorizations, new destination addresses, and outflows on several chains at once, and keep a tested way to pause withdrawals.
- Test the path from laptop to signer. Assume one engineer's device is compromised and check what it reaches, which is exactly what an internal penetration test is built to map: containers, CI/CD pipelines, secrets stores, and signing APIs.
Must Read: GitLab CVE-2026-110264
Why the Path to the Signer Is the Real Target
Hardware security modules protect keys, but a protected key still signs whatever the system around it asks it to sign. That's the uncomfortable lesson here. If Binance's preliminary finding holds, the attacker never needed the key; they needed to reach the system that uses it.
The same pattern hit Bybit in February 2025, a theft the FBI attributed to TraderTraitor. There, attackers compromised a wallet provider's developer and tricked signers into approving a malicious transaction. In both cases the weak point was the route to the signer, not the key store. That route almost always runs through ordinary IT: a laptop, a stolen credential, a CI/CD pipeline, a service container. Securing it means assuming an attacker can get one foothold and making sure that foothold can't quietly tell your signer to move funds.
Also Read: How Attackers Sell Initial Access on the Dark Web
How OraSec Can Help
OraSec tests how attackers move from one compromised device to the systems that matter. Our red team engagements start from a realistic foothold, such as a developer laptop, and try to reach production containers, CI/CD, secrets, and payment or signing services. Our threat hunting team checks endpoint, container, and access logs for signs someone already has that foothold. Testing is manual, findings come with evidence and fix guidance, and we retest after you fix.
Helpful for you: CVE-2026-109618 vs CVE-2026-109619
Conclusion
The Binance hack moved about $6.3 billion out of hot wallets in a few hours, and early findings point to a possibly compromised engineer's laptop and a service container, not leaked keys. Attribution and root cause are still open. In the meantime, the question worth asking isn't only "are our keys safe?" but "who and what can ask our signing and payment systems to move money, and would those systems say no?"
Frequently Asked Questions
Was Binance hacked?
Yes. Binance confirmed a security incident with an estimated impact of about $6.3 billion and temporarily suspended deposits and withdrawals.
Were Binance's private keys stolen?
Binance says it has found no evidence of a private key leak so far, and Blockaid points to signing infrastructure rather than a leaked key. Some outside experts disagree, so the root cause isn't settled.
Did North Korea hack Binance?
TRM Labs and Chainalysis attribute it to North Korea's TraderTraitor, and the FBI has linked the group to it. Binance hasn't formally confirmed attribution.
How much of the stolen crypto was frozen?
Binance says about $3 billion. Analysts note that most frozen funds are stablecoins, such as Tether's USDT and Circle's USDC, which issuers can freeze; assets like ETH and BTC can't be.
Is this the largest crypto hack ever?
TRM Labs and Chainalysis both call it the largest crypto theft on record, roughly four times the ~$1.5 billion Bybit theft of February 2025.
Will Binance customers lose money?
Binance says it will cover all losses through its SAFU fund and its own reserves.



