Bitget hack: how $387 million left without a stolen key

26 September 2026

Illustration of how the Bitget hack worked: the wallet backend was compromised, a spoofed transfer request was created, the approval step passed it, and the hot wallets were drained of about $387.5 million, while the offline cold wallets stayed untouched

At 18:31 UTC on 24 September 2026, Bitget’s systems flagged transfers nobody had asked for. By the time the exchange finished counting, about $387.5 million had left its hot and warm wallets. Nobody stole a private key.

The Bitget hack wasn’t a broken lock. Attackers got into a backend system in Bitget’s wallet infrastructure, faked the transaction data, and let the exchange’s own approval process send the money out. It’s the largest cryptocurrency hack of the year to date.

That’s the part worth sitting with. The approval step did exactly what it was built to do: it checked a request, found it valid and let it through. It never had a way to ask whether the request itself was real.

What happened in the Bitget hack?

Bitget’s security systems detected unauthorised transfers from some of its hot wallets at 18:31 UTC on 24 September. The exchange first put the loss at $351.6 million, as CoinDesk reported that evening, then raised it to about $387.5 million after counting Zcash and additional TRON transfers. Bitget called the revision “a fuller accounting of transfers during the incident, not more theft”.

The next day, chief executive Gracy Chen explained how. The attacker “compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process to move funds out”. The hot and warm wallets were hit. Bitget says its offline cold wallets stayed secure.

Bitget paused withdrawals and kept deposits and trading open. It has brought in Mandiant and SlowMist to investigate, and some blockchain foundations have frozen attacker addresses. As of 26 September, withdrawals were still paused, and Bitget had promised a full incident report.

Who was behind the Bitget hack?

Nobody has confirmed it yet. Bitget says the attack is “highly consistent with known patterns of North Korean hacker organizations”, based on IP behaviour and on-chain analysis. The blockchain analytics firm Elliptic assessed it as “highly likely” linked to North Korea: some of the stolen funds touched addresses used to launder the 2025 Bybit theft. If that holds, Elliptic says it’s the largest suspected North Korean crypto theft of 2026, and it pushes their total for the year past $1 billion.

Treat “highly likely” as what it is. For Bybit, the FBI named North Korea within five days. For Bitget, no government has said anything yet.

Is Bitget safe for users in India right now?

Bitget says no customer loses money: the loss falls within its User Protection Fund, which it says holds over $464 million, and account balances remain accurate. That’s the exchange’s own statement, and it’s the most anyone can say until the incident report is out.

What it means in practice:

Until withdrawals resume, you can’t move funds out. Watch Bitget’s official announcements, not screenshots forwarded in groups.
Ignore anyone who contacts you offering to “recover” funds from the hack or to speed up your withdrawal. A hack in the news is exactly when those messages appear, and your funds aren’t missing in the first place.
Don’t install any Bitget “update” or app sent as a file. Apps come from the Play Store or App Store. We explained why in our post on APK file scams.

On the question of Bitget’s registration with FIU-IND, India’s Financial Intelligence Unit, we couldn’t confirm its current status from the regulator’s own list. In July 2024, Bitget told Cointelegraph it had applied and was “in talks with the regulators”. If registration matters to where you keep money, check the list on fiuindia.gov.in yourself.

India has been here before. WazirX lost $230 million in July 2024, and CoinDCX lost $44.2 million in July 2025, the second from an internal operational account rather than customer wallets.

Why does this matter? Two record hacks, one weak point

Bybit’s $1.5 billion loss in February 2025 went the same way. There, attackers had compromised a developer machine at its wallet provider, Safe{Wallet}, and masked the signing interface so Bybit’s signers approved a transaction that looked routine. The FBI attributed it to North Korea.

	Bybit, February 2025	Bitget, September 2026
Amount	About $1.5 billion	About $387.5 million
Private keys stolen?	No	No, according to Bitget
What was compromised	A developer machine at the wallet provider	A backend system in the wallet infrastructure
What the approval saw	A masked signing screen that looked routine	Spoofed transaction data
Attribution	North Korea, named by the FBI	North Korea suspected by Bitget; “highly likely” per Elliptic

Neither attack broke the cryptography. Both went around it, by controlling what the approval step was shown. The keys were safe the whole time. They just signed the wrong thing.

Keys protect the signature. Nothing protects what gets put in front of it, unless you build that part too.

For businesses: ask where your approvals get their facts

You don’t need to run an exchange for this to apply. Any system that moves money has an approval step: payouts, refunds, vendor payments, wallet transfers. The useful question for a vendor or your own team isn’t “are the keys safe?” It’s this: if the system that creates a payment request is compromised, what stops the request from being approved?

Finance teams know the everyday version. An invoice arrives with new bank details, every check passes because every check trusts the invoice, and the money goes to the wrong account. Same shape, smaller number.

For developers: build approvals that don’t trust their inputs

These are the controls we’d look for in any system that moves money. They’re general practice, not a claim about how Bitget’s system was built:

The approver rebuilds the transaction from its own source of truth, rather than signing a payload handed to it.
What the approver sees is what gets signed. Show the destination and amount from the transaction itself, not from a separate display layer.
New withdrawal destinations wait before first use. An allowlist with a delay turns a one-minute theft into a window for someone to notice.
Hot wallets hold only what daily operations need, with velocity limits that pause large or unusual outflows for a human.
Alerts fire on first-time destinations and on volume spikes, to someone who can stop the flow.

What this post doesn’t cover

This isn’t investment advice, and it isn’t the root cause. Bitget’s incident report will say which backend system was compromised and how, and we’ll update this post when it’s published. Until then, anything more specific about the entry point is guesswork.

The Agneya perspective

Security conversations still start with keys: where they’re stored, who holds them, whether they’re in hardware. That work matters, and in both of these hacks it held. What failed was quieter. A trusted step accepted what a trusted system told it.

That’s the review we’d want for any product that approves money moving: trace every approval back to where its data comes from, and ask what happens if that source lies. It’s the same instinct behind the seven checks we run before quoting on a codebase.

If your product approves payouts, refunds or transfers, we can walk through where its approval step gets its facts. Tell us what you need.