Build2 publishers3 min readPublished
Falsified wallet-backend data pushed $387.5M out of Bitget through its own approvals
Bitget lost $387.5 million after attackers inside its wallet backend falsified transaction data that its own authorization process then approved. Its CEO says the private keys stayed safe, so the failure sat in the step between approval and signature.
The Engineer · Build desk
What happened
- Chief executive Gracy Chen said the attack bore the hallmarks of North Korean state hackers, citing IP addresses tied to VPN infrastructure those groups had used before.
- Early on-chain analysis put the loss at $170 million to $183 million, and Bitget's first official figure of $351.6 million was later revised upward by audits.
- Mandiant and SlowMist are assisting the investigation, and Bitget says industry partners have helped freeze some of the stolen assets.
- Bitget says its User Protection Fund, stated at more than $464 million, will cover the full loss.
- Withdrawals were halted while deposits and trading kept running, and a staggered withdrawal schedule begins on Monday, September 28.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Key storage held and the funds left anyway, so hardening key storage alone does not close this path; the signer also has to check each payload against the approval it claims to carry.
- exposure Where authorization runs on whatever the transaction backend submits, write access to that backend reaches the whole hot and warm wallet balance, whether the writer is an outside attacker or an insider.
- cost Bitget absorbs the loss from a fund it sizes at just over $464 million, using up to about 84% of it and leaving at least $76.5 million against the next claim.
According to Bitget, the attackers got into a critical backend in the exchange's wallet infrastructure and used it to falsify transaction data [2]. Bitget's legitimate authorization processes then ran on that data and pushed the transfers through [3]. The exchange has not disclosed how the attackers got in, which fields they changed, or how its signing system is built [4][5].
The public accounts describe the break in two ways. Tom's Hardware, reporting Chen's livestream, says the backend forged transfer approvals that tricked the system into authorizing the transactions [6]. The dev.to incident summary says falsified data triggered genuine authorization, and adds that this does not confirm stolen keys or traffic altered in transit [3]. Those are different missing checks. A forged approval means the signer accepted an approval it could not authenticate. A genuine approval over tampered data means the approval was never bound to the bytes that got signed.
Either way, the signer did what it was asked to do. The summary's general advice covers both cases. It proposes keeping transaction generation apart from signing, and re-verifying destination, amount, chain ID and nonce in an independent component immediately before signing [7]. It says that advice is general and does not describe Bitget's configuration [8]. Independence is the hard part. A verifier that reads its copy of the approved transfer from the backend that built the payload will find a match every time that backend is compromised. The design I would approve has the approver sign a hash over those four fields. The signer then recomputes that hash from the payload in front of it and refuses on a mismatch. That costs a separate service with its own credentials and deploy path, plus a round trip on every hot-wallet withdrawal.
Timing limits the other controls. The attackers swapped USDT, USDC and tokenized gold into ETH on decentralized exchanges within minutes of the theft, to get around stablecoin blacklisting and freezes [9]. Native assets such as XRP, ETH, BNB and TRX were split across dozens of new attacker-controlled wallets [10]. The summary lists as a precondition that assets sat in hot and warm wallets with no manual or automated stop control firing before the transfers completed [11]. Its proposed backstops are smaller online hot-wallet balances and an emergency kill switch that halts transfers on every chain at once [12]. Bitget's recovery bounty pays up to 5% of funds frozen or recovered [13]. On the full $387.5 million [1], that tops out near $19.4 million [3].
The accounts also list different networks. The dev.to summary names EVM-compatible chains, the XRP Ledger, Zcash and TRON [14]. Tom's Hardware lists Ethereum, the XRP Ledger, Avalanche, BSC and Arbitrum [15]. Bitget says it has fixed the backend vulnerability [22].
What to watch
- A technical disclosure from Bitget, Mandiant or SlowMist stating which transaction fields were altered and whether the approvals were forged or genuine.
- Whether the staggered withdrawals starting September 28 run to schedule, and whether Bitget states new limits on hot-wallet balances.
- How much of the fragmented ETH, XRP, BNB and TRX is frozen or returned under the up-to-5% bounty.