Bitget Hack Explained: Fake Orders, Real Signatures

How does an exchange sign away $387.5 million without anyone stealing a key? Bitget CEO Gracy Chen gave part of the answer on September 25, the day after the hack: an attacker compromised a backend system in the wallet infrastructure and spoofed transaction data. On September 28 she added how the attacker got in. According to The Hacker News' report on her livestream and interviews, the attacker exploited a flaw in a third-party security product, obtained high-level internal credentials and used them to push fraudulent withdrawal commands into Bitget's wallet services, which treated the commands as real. Bitget says no private key was taken. The signer did its job on false instructions. The company has not named the product, and it said on September 28 that a formal incident report would follow that week.

What Bitget says happened in the hack

Chen's account, as reported by The Hacker News and by Cointelegraph, starts with a flaw in a third-party security product that gave the attacker high-level internal credentials. The credentials opened an internal management system. From there the attacker inserted fraudulent withdrawal commands into wallet-related backend services, where they passed as legitimate. The attacker disguised the activity as routine administrative work and removed traces of it. Two small test transfers at 18:31 UTC on September 24 stayed under Bitget's risk-control threshold and raised no alert. The larger transfers began about 30 minutes later, and Bitget says its wallet system executed them past its risk controls.

Bitget says its cold wallets were untouched and customer balances are intact, with its Protection Fund covering the loss. Bitcoin withdrawals reopened on September 28, and other assets return in stages through October 2. Mandiant and SlowMist are supporting the investigation. Two early details have changed since the first statements. The loss figure rose from $351.6 million to $387.5 million after Bitget added Zcash and Tron assets, and Chen now calls the earlier suggestion of North Korean involvement preliminary indicators that are still being assessed. TRM Labs found overlaps with wallets that laundered earlier North Korean thefts but has not made a firm attribution.

The Bitget hack timeline, second by second

Hypernative, a blockchain security firm, reconstructed the drain from on-chain data. At 18:31 UTC, two small transfers, 0.84 ETH and 93 TRX, went to fresh addresses 11 seconds apart. The attacker then waited 28 minutes. At 18:58 the first large transfer went out, 34.75 million USDT. At 19:01, hot wallets sent $87.6 million in seven transfers across five networks in 15 seconds. At 19:16, warm wallets sent $202.8 million across five networks in 9 seconds. Those 24 seconds carried about $290 million, about three-quarters of the total. Transfers landing on unrelated chains within the same few seconds suggest one process inside Bitget was sending requests to every chain's signer at once. Signing continued until 21:23:11, 2 hours and 52 minutes after the first test.

The gas-limit tell in the Bitget hack

Every Ethereum-style transaction carries a gas limit, a cap on the work it may use. Bitget's system computes one for each withdrawal, so its values vary: 63,000 or 136,620, for example. The attacker's requests carried round numbers instead: 100,000, 200,000 and 50,000,000. On all six EVM networks the fee settings matched Bitget's customer withdrawals, and the gas limit was the one field that differed. Hypernative argues that the first test transfer, at 18:31:11, was the earliest point where a check before signing could have caught the fraud. That conclusion comes from a firm that sells pre-signing transaction checks, so read it with that in mind, but the on-chain numbers are public and anyone can look them up on a block explorer. The tell has limits. XRP Ledger and Tron transactions have no comparable field, and the three non-EVM networks, counting Zcash, account for about half of the loss.

What a miner can take from the Bitget hack

Hypernative's advice for exchanges reduces to one rule: a signer should not take a destination and an amount from an internal service without checking them against a record that service cannot write to. A miner faces a smaller version of the same question, and it starts with the payout address in the rig's configuration. Payout Preflight rebuilds the coinbase transaction NexusPool would pay for a Bitcoin address you enter, using the same code that builds real blocks, so you can compare the destination with your wallet while nothing is at stake. NexusPool's technology page explains the payout path: the coinbase output pays the finder's own address, so the pool keeps no balance and runs no withdrawal queue for anyone to feed a fake command into. The place a pool could go wrong is the coinbase itself, which is why the preflight exists.

The claim is narrow. A coinbase paid to your address still depends on you keeping that address's keys, and nothing here makes solo mining a place to keep savings. Your chance of finding a block is your hashrate divided by the network's, the same at every pool, NexusPool included, and no payout design changes it. Payout Preflight shows where a reward would land. It does not audit anyone's code, ours included. The terms cover the rest.

So how does an exchange sign away $387.5 million with no stolen key? It signs what a compromised system tells it to sign. Bitget's incident report may change details of this account, including which product failed, and the useful part will survive it: a valid signature proves who signed and says nothing about whether the order was real. Trust nothing. Verify where a payout lands before the block arrives, not after.