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.
Why it matters
- Who has to decide 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.
- Who's exposed 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.
- What it costs 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.
Next story · Invest · Oct 3
Issuers and protocols have frozen about 0.2% of the $387 million taken from BitgetConfirmed3 publishers
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 [15][16].
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 [4]. 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 [17]. It says that advice is general and does not describe Bitget's configuration [18]. 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 [5]. Native assets such as XRP, ETH, BNB and TRX were split across dozens of new attacker-controlled wallets [6]. 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 [19]. Its proposed backstops are smaller online hot-wallet balances and an emergency kill switch that halts transfers on every chain at once [20]. Bitget's recovery bounty pays up to 5% of funds frozen or recovered [7]. On the full $387.5 million [1], that tops out near $19.4 million [25].
The accounts also list different networks. The dev.to summary names EVM-compatible chains, the XRP Ledger, Zcash and TRON [8]. Tom's Hardware lists Ethereum, the XRP Ledger, Avalanche, BSC and Arbitrum [9]. 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.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Not scored
- Hype gap+15
- Incentives60
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Bitget confirmed that approximately $387.5 million worth of assets was transferred from multi-chain hot and warm wallets to attacker-controlled addresses following the compromise of a critical backend system and the abuse of authorization processes.
- [2]
According to Bitget, attackers compromised a critical backend within the exchange's wallet infrastructure and manipulated (falsified) transaction data to abuse authorization processes.
- [3]
Based on the falsified transaction data, legitimate authorization processes were triggered, advancing the transfer process; this does not confirm that signing keys were directly stolen or that communications were intercepted and altered in transit.
- [4]
According to CEO Gracy Chen as reported by Tom's Hardware, the hackers exploited a backend wallet system that processes wallet transactions, forging transfer approvals that tricked the system into authorizing the fraudulent transactions.
- [5]
The hackers converted USDT, USDC and tokenized gold (XAUt) directly into ETH on decentralized exchanges within minutes of the theft to circumvent on-chain blacklisting or freezing of the stablecoins.
- [6]
Native layer-1 assets like XRP, ETH, BNB and TRX were quickly fragmented and distributed across dozens of new attacker-controlled wallets.
- [7]
Bitget launched a recovery-bounty program offering rewards of up to 5% for funds successfully frozen or recovered.
- [8]
Assets were transferred from hot and warm wallets spanning EVM-compatible chains, XRP Ledger, Zcash and TRON.
- [9]
The stolen assets include Ether, XRP, USDT, USDC, Avalanche and BNB across the Ethereum, XRP Ledger, Avalanche, BSC and Arbitrum networks.
- [10]
Gracy Chen confirmed that cold wallets and private keys remained safe and uncompromised.
- [11]
Speaking during an X livestream on the evening of the September 24 hack, CEO Gracy Chen said the attack bore the hallmarks of North Korean state-sponsored threat actors, citing suspicious IP addresses tied to VPN infrastructure previously used by North Korean hacker groups.
- [12]
Early independent on-chain analysis put the stolen value at $170 million to $183 million; Bitget announced an initial official value of $351.6 million, and comprehensive audits revised the final official value to $387.5 million.
- [13]
Bitget announced that its User Protection Fund of over $464 million would cover the full loss.
- [14]
Bitget temporarily froze user withdrawals while deposits and trading remained functional, and is rolling out a staggered withdrawal schedule starting Monday, September 28.
- [15]
Specific initial access vectors or vulnerabilities used in the breach have not been disclosed.
- [16]
Specific data fields that were altered and internal signing implementation details have not been disclosed.
- [17]
The report proposes strictly separating transaction generation systems from signing systems, re-verifying destinations, amounts, chain IDs, and nonces in an independent component immediately before signing.
- [18]
The defensive measures in the report are general proposals and do not directly indicate internal configurations or implemented measures published by Bitget.
- [19]
A listed precondition of the attack was the existence of target assets in hot and warm wallets without manual or automated stop controls triggering before transfer completion.
- [20]
The report proposes minimizing online hot wallet balances to operational necessities and establishing an emergency kill switch to immediately halt transfers across all chains.
- [21]
Bitget is tracing funds with industry partners and reports some assets have been frozen through their cooperation; Mandiant and SlowMist are assisting with the investigation.
- [22]
Bitget says it has fixed the backend vulnerability.
- [23]
The $387.5 million loss equals at most about 84% of the User Protection Fund's stated size of more than $464 million.
- [24]
After covering the loss, at least $76.5 million of the fund's stated size remains.
- [25]
A 5% bounty on the full $387.5 million would come to about $19.4 million.
Sources
2 independent publishers whose own reporting we read for this story.
- dev.toBitget: $387.5M Stolen via Wallet Backend Compromise and Transaction Data Tampering
1 article · September 28, 2026
- tomshardware.comNorth Korea named as primary suspect in $387 million Bitget crypto hack
1 article · September 28, 2026
Topics and entities
Topics
- Crypto Exchange Security Operations
- Hot and warm wallet custody
- State-sponsored crypto theft
Entities
- Gracy Chen
- North Korean state-sponsored hackers
- SlowMist
- Bitget
- Mandiant