Menu
Breach value calculatorCalculator

Binance Hack 2026: The $6.3bn Hot-Wallet Loss and What to Do Now

Binance says its hot wallets were compromised on 29 Oct 2026, with about $6.3B in token assets taken. What's confirmed, what isn't, and what to do.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

In the 2026 Binance hack, the exchange says its hot wallets were compromised at around 20:05 UTC on 29 October, and unauthorised withdrawals took about $6.3B in token assets. As of Binance's Update #3 (31 Oct), withdrawals have not yet resumed, and Binance says it remains on track to reopen them on Sunday 1 November. It says it has now covered up to 90% of the loss from its own funds, and has found no evidence that wallet private keys leaked.

As of Binance's "Security Incident | Recovery Update #3", which the page shows as published 2026-10-31 14:24 (no time zone given). Read 31 October 2026. This is a developing story, and this post will be updated as Binance publishes more.

A hot wallet is the part of an exchange's crypto that sits on internet-connected systems so customer withdrawals can be paid quickly. Our custody guide explains how it differs from warm and cold storage.

Everything below about the incident comes from Binance's own announcements. Binance has not named an attacker, and neither do we. More on exchange and wallet security is in our Crypto Security section. It is security guidance, not investment advice.

What happened in the Binance hack on 29 October 2026?

Binance has published three updates so far. Its first update gave an early theory: the incident may involve "a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container". That access, it said, was used to submit unauthorised withdrawals.

The second update widened the picture. It says the investigation "has uncovered additional points of breach" beyond the laptop. It does not yet say what they are.

The third update is about recovery: how much of the loss Binance has replenished, the Proof of Reserves snapshot and the withdrawal restart. It gives no new root cause and no attribution.

Binance's account, in order. Only some rows have a time zone in the source; the publication times are shown as Binance's pages display them.

When (as Binance gives it) What Binance says
2026-10-29, around 20:05 UTC "our hot wallets were compromised", with unauthorised withdrawals
2026-10-30, published 02:23 (no time zone shown) First update: estimated impact "around $6.3B"; "~$3 billion frozen on-chain so far"; withdrawals suspended; "the affected address authorisation" revoked; law enforcement and blockchain intelligence partners engaged
2026-10-30, updated 11:36 (no time zone shown) First update amended to say deposits "remain unaffected and continue to operate as normal"
2026-10-30, published 19:33 (no time zone shown) Update #2: loss of "approximately $6.3B USD worth of token assets"; more than $6.34B set aside; about 80% covered; "additional points of breach" found; compromised infrastructure contained; "Deposits and other unaffected platform services remain operational"
About 12 hours after Update #2 Update #2's plan: initial Proof of Reserves snapshot
About 34 hours after Update #2 Update #2's target to "start resuming the withdrawal service", in phases
About 48 hours after Update #2 Update #2: further technical findings expected, "once they have been verified"
2026-10-31 00:00 (UTC) Proof of Reserves snapshot taken, per Update #3
2026-10-31, published 14:24 (no time zone shown) Update #3: "That covered amount is now up to 90%"; top ten tokens "fully backed 100%"; snapshot already on the Proof of Reserves site; withdrawals not yet resumed
Sunday 2026-11-01 Update #3: Binance "remain[s] on track to reopen withdrawals"
Monday 2026-11-02 Update #2's expected date for the Proof of Reserves result
Tuesday 2026-11-03 (UTC) Update #3's estimate for the full zero-knowledge proof

The 12, 34 and 48 hour targets are Binance's estimates from Update #2. That update does not turn them into clock times, so we don't either. Update #3 gives a day for withdrawals: Sunday 1 November.

Are Binance users' funds safe?

Binance's answer is yes. The first update says "User funds are safe" and that Binance "will cover all losses from the SAFU fund and the company's funds". SAFU, the Secure Asset Fund for Users, is the emergency fund Binance keeps for incidents like this. Update #3 repeats the point: Binance "will absorb the financial impact of these stolen funds, not our users".

Update #2 gave the numbers behind that promise, in Binance's words:

  • "We have already set aside more than $6.34B in company funds, with $5B held in the exact impacted token assets that were stolen", which Binance lists as including USDC, USDT, BTC, ETH and BNB.
  • "This means that we have already covered approximately 80% of the impacted amount." Binance said it was buying the rest.
  • "Approximately $3 billion has been frozen on-chain to date."
  • "At this stage, we have found no evidence that wallet private keys were leaked."

Update #3 moves the coverage figure on:

  • "That covered amount is now up to 90%", up from about 80% in Update #2.
  • The money comes from a partial deployment of SAFU, which Binance says is "expected to happen over the next 24 hours", a portion of its Futures insurance fund, and its corporate treasury.
  • The top ten tokens are "fully backed 100%". The remaining 10% is in less liquid tokens outside the top ten.

These are Binance's statements, not independent findings. Binance says the Proof of Reserves snapshot, taken at 2026-10-31 00:00 (UTC), is already on its Proof of Reserves site. A Proof of Reserves is an exchange's attempt to show that the assets it holds match what it owes customers. It shows balances at one moment; it is not a full audit.

The full zero-knowledge proof takes about 40 to 50 hours to generate, and Binance estimates it for Tuesday 3 November (UTC). A zero-knowledge proof is a cryptographic method for proving a statement is true without revealing the underlying data.

What is known, and what is not yet known?

Question Known (per Binance) Not yet known
When Around 20:05 UTC, 29 October 2026 How long the attacker had access before that
How much About $6.3B in token assets Which tokens, and how much of each
How they got in First suspected a compromised DevOps engineer's laptop and a service container; later found "additional points of breach" What those other points are, and the root cause
Keys No evidence so far of a private key leak Whether that changes as the investigation continues
Who Binance has not named anyone Any attribution by Binance or law enforcement
Recovery Up to 90% of the loss covered from Binance's funds (Update #3); about $3B frozen on-chain (Update #2) How much of the frozen amount will be returned, and when the last 10% is covered
Withdrawals Not yet resumed as of Update #3; reopening targeted for Sunday 2026-11-01 When every asset is available again
Reserves Snapshot taken 2026-10-31 00:00 (UTC) and published The full zero-knowledge proof, estimated for 2026-11-03 (UTC)

Binance promises a detailed technical post-mortem once its investigation is complete. Update #3 gives no date for it. Until then, any account of the attack path beyond the table above is speculation, including ours.

Who was behind the Binance hack?

As of 31 October 2026, Binance has not named an attacker, and Update #3 adds no attribution. Its second update says it is working with law enforcement and will "pursue all available avenues to identify those responsible and hold them accountable".

What should Binance users do now?

Most of the risk to individual users right now comes from the noise around the incident, not the incident itself. Big breaches draw scammers who pose as support staff, recovery agents or "refund" services.

  1. Get updates only from Binance's official announcement page and the app itself. Type the address yourself rather than following links in messages.
  2. Treat any "refund", "compensation" or "recovery" offer as a scam until proven otherwise. Binance says it is absorbing the loss from its own funds. The three updates we read describe no claim process for users.
  3. Never share 2FA codes, passwords, recovery phrases or remote-screen access with anyone, whoever they say they are. Real support staff don't need them.
  4. Don't pay a fee to "unlock" or "speed up" a withdrawal. Binance describes the pause as a security measure, not a queue you can pay to skip.
  5. Check your own account security: confirm your 2FA method, review active sessions and devices, and check your withdrawal address allowlist if you use one.
  6. Keep records of your balances and any messages you receive, in case you need them later.

Recovery scams are a known pattern after crypto losses. Our analysis of FBI crypto fraud data sets out how they work and the warning signs.

Whether to keep funds on any exchange is a personal decision. We don't give investment advice.

How is this different from the 2025 Bybit hack?

Both are exchange thefts measured in billions. Bybit's cause has been set out by investigators. Binance's is still an early theory: its first update says the incident "may involve" an engineer's laptop.

  • Whose systems. Forensic work on Bybit placed the compromise at Safe{Wallet}, an outside wallet service, starting with a developer machine, not inside Bybit (Sygnia). Binance's early account points to its own engineer and its own infrastructure.
  • Which wallet. Bybit's funds left its Ethereum cold wallet after the web code shown to its signers was tampered with. Binance says hot wallets were hit.
  • Who did it. For Bybit, and only Bybit, the FBI publicly attributed the February 2025 theft to North Korea (FBI IC3). For Binance, no one has been named.

Nothing in the sources we read links the two incidents. Comparing them is not a suggestion that the same attacker is involved.

The full Bybit story, with its timeline and sources, is in our Bybit case file.

Going deeper: for security and IT teams

Everything in this section is a general lesson for any organisation that moves value from online systems. Binance has published only the outline above. Nothing here is a claim about how Binance's systems are built or what failed inside them.

The threat model Binance's wording describes. An attacker gets onto an engineer's laptop, uses it to reach a production service, and has that service submit withdrawals.

Binance says it has no evidence keys leaked. If that holds, the general point is that the key does not have to be stolen if the system allowed to ask for signatures is compromised. The approval path in front of the key deserves the same protection as the key.

Engineer devices are a documented way in. In a 2022 joint advisory, the FBI, CISA and the US Treasury described a campaign against "cryptocurrency exchanges" and other crypto firms in which "Intrusions begin with a large number of spearphishing messages sent to employees", often dressed as job offers (CISA AA22-108A). The attackers then "propagate malware across the victim's network environment" and "steal private keys or exploit other security gaps". This is cited as a pattern only. Binance has not linked its incident to that campaign or any other.

Map it to ATT&CK. Once an engineer's access is used by someone else, the relevant technique is T1078 Valid Accounts ("Adversaries may obtain and abuse credentials of existing accounts"). MITRE's mitigations make a practical checklist:

  • M1036 Account Use Policies: "Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges." Production access should work only from managed, healthy devices.
  • M1026 Privileged Account Management and M1018 User Account Management: audit who holds production rights, and remove standing access nobody uses. Our recommendation on top: grant production rights just in time, for a named task, and expire them.
  • M1032 Multi-factor Authentication across every account type, including service accounts where the platform allows.
  • M1013 Application Developer Guidance: "Ensure that applications do not store sensitive data or credentials insecurely." Containers and laptops should not hold long-lived tokens for the signing path.

Stolen sessions get around login MFA. Our post on infostealers and session token theft covers device-bound sessions.

Hot-wallet limits. A hot wallet's balance is the most an attacker can take in one go from that layer. Size it to expected withdrawal demand, top it up from colder storage through a separate, slower approval, and treat a top-up request outside normal patterns as an incident signal.

Withdrawal anomaly controls. Put a policy engine between the service that requests withdrawals and the service that signs them, and make it enforce limits the requesting service cannot change: per-asset and total outflow per time window, new-destination holds, and an automatic halt when thresholds trip. Binance's first update says it "revoked the affected address authorisation", which shows why destination-level authorisation is worth having: it can be pulled quickly.

Detection. The T1078 page lists detection strategy DET0560, "Detection of Valid Account Abuse Across Platforms", which includes analytics for unusual-time remote logins by service accounts (AN1545), identity-provider sign-in anomalies (AN1546) and containerised service accounts and kubeconfigs (AN1547). Add alerts on new withdrawal authorisations, requests from service identities that don't normally make them, and outflow spikes measured across all assets, not per transaction.

Containment depends on outside parties. Binance credits on-chain freezes with about $3 billion so far and says it is working with "law enforcement, blockchain intelligence firms, token issuers and other exchanges". Freezing depends on those parties acting fast. Keep current contacts for each token issuer and analytics provider in your incident plan.

Questions to ask your own team or custodian:

  • Which people and devices can reach the systems that request or approve withdrawals?
  • Can a single compromised service move funds without a second, independent check?
  • What is the hot-wallet ceiling per asset, and who can raise it?
  • Which outflow thresholds halt withdrawals automatically, and when were they last tested?
  • How quickly can we revoke an address authorisation or a service credential, and who has that power out of hours?

Key takeaways

  • Binance says its hot wallets were compromised at around 20:05 UTC on 29 October 2026, with about $6.3B in token assets withdrawn without authorisation.
  • As of Update #3 (31 Oct), withdrawals have not yet resumed. Binance says it remains on track to reopen them on Sunday 1 November.
  • Binance says it will absorb the loss, not its users. Covered funds rose from about 80% (Update #2) to up to 90% (Update #3), drawn from SAFU, part of its Futures insurance fund and its corporate treasury. About $3B is frozen on-chain.
  • The top ten tokens are fully backed; the last 10% is in less liquid tokens. A Proof of Reserves snapshot from 31 October 00:00 UTC is published, and the full zero-knowledge proof is estimated for 3 November (UTC).
  • It found no evidence of a private key leak so far. The first suspected entry point, an engineer's laptop, has since been joined by "additional points of breach".
  • No attacker has been named. The token breakdown, root cause and post-mortem date are not yet public.
  • For users: official channels only, ignore refund offers, never share 2FA codes.
  • For security teams: protect the systems that can ask for a signature as carefully as the keys, and cap what a hot wallet can lose.

Sources

All read on 31 October 2026.

Spotted a mistake? Report a correction.