On 24 September 2026, between 18:31 and 21:23 UTC, Bitget's own hot and warm wallets sent ~$387M to an attacker. By Bitget's account, the attacker had compromised a backend system in its wallet infrastructure and used it to feed spoofed withdrawal requests into its authorization process. It appears to be the largest crypto theft of 2026 by value so far, and suspected North Korean crypto thefts now pass $1B for the year.
Bitget says its User Protection Fund will cover customer losses and that withdrawals will reopen in stages from 28 September, starting with BTC. Any exchange or custodian whose signer takes a transfer's destination and amount from an internal service, without checking them independently, has the same gap.
What happened
Onchain, Bitget's custody looks tiered. High-volume hot wallets serve customer withdrawals and sign hundreds of transactions an hour. Lower-volume warm wallets hold larger balances and top up the hot tier, and cold storage sits behind both.
On 25 September, CEO Gracy Chen described the cause: "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. Private key compromise has been ruled out."
The next day, Bitget said the vulnerability was identified and remediated and that Mandiant and others are supporting the investigation, but it hasn't published a technical report. Each attacker transfer is an ordinary, valid transaction from a Bitget wallet, sent to an address the attacker controlled.
Recent estimates place the loss at more than $387M. Bitget revised its figure from $351.6M to $387.5M on 25 September after adding the Zcash and Tron assets, and Hypernative’s onchain analysis of the attacker's transfers matches.
Timeline of the drain
The attacker tested the route first. At 18:31, two small transfers, 0.84 ETH and 93 TRX, went to fresh addresses 11 seconds apart. The attacker then waited 28 minutes before sending the first large transfer, 34.75M USDT, at 18:58. After that the loss came in two waves.
At 19:01, hot wallets sent $87.6M in seven transfers across five networks in 15 seconds. At 19:16, warm wallets sent $202.8M across five networks in 9 seconds. Those 24 seconds carried ~$290M, about three-quarters of the total. Transfers landing on unrelated chains within the same few seconds suggest a single process inside Bitget was sending requests to every chain's signer at once.
How spoofed requests got signed
Bitget's CEO has said no private key was stolen, and the onchain data is consistent with that. On all six EVM networks, the attacker's transfers used the same fee settings as Bitget's customer withdrawals sent around the same time but only the gas limit was different. The defense has to check what the signer is being asked to sign.
Every transaction on Ethereum-style networks carries a gas limit, a cap on how much work (and so fee) it's allowed to use. Bitget's system calculates this for each withdrawal, so its values look like 63,000 or 136,620. The attacker's requests arrived with fixed round numbers instead: 100,000, 200,000 or 50,000,000. Everything else about them looked like Bitget's own traffic, so this one signal gave them away, and it's something a system can check automatically before a transaction is signed.
On Bitget 6, the only native ETH sent were the attacker's four transactions: 0.84 ETH, 7,130.86 ETH, 1,879.20 ETH and 223.20 ETH.
The gas-limit signal is strongest on the high-volume hot wallets. Bitget 35, a low-volume warm wallet, uses round gas limits in its routine traffic, and XRPL and Tron transactions have no comparable field.
Where the funds went
XRPL carried the largest share at $157.7M, ahead of Ethereum at $126.5M. With the probable ~$29.4M Zcash leg and Tron's $7M, the three non-EVM networks account for about half of the total. Monitoring built only for EVM chains would have covered the other half.
The laundering route appears to have been ready before the first transfer. About ~$88.3M left Bitget as USDT, USDT0, USDC and XAUt, all assets their issuers can freeze. The USDT reached a swap hub (an EIP-7702 account delegated to MetaMask's smart-account contract) and was being sold for ETH through UniswapX fillers and Uniswap pools 1 minute 48 seconds after it arrived.
Proceeds on Base, Optimism, Arbitrum and BSC Chain were bridged back to Ethereum through intent-based bridges, and the Avalanche proceeds returned as USDC through Circle CCTP. The ETH was then split, mostly into round 10,000 ETH lots.
At Hypernative's snapshot (~11:30 UTC on 25 September), ~68,295 ETH sat in eight wallets that had never sent a transaction, and 102.28M XRP sat in five XRPL accounts, one of which had started peeling off small amounts. The only real exit by then was ~5,032 BNB swapped to Bitcoin through THORChain, and the 20.59M TRX had started dispersing to 13 addresses. That left ~$341M not yet laundered. Since then, the attacker has begun moving the XRP: ~54M had left the original accounts by 26 September.
None of the venues the attacker used was exploited, and their users aren't affected. Uniswap, MetaMask Bridge and Swaps, LI.FI, Across, Stargate, deBridge, Relay, Mayan, Celer, PancakeSwap, THORChain and Circle CCTP appear only as routes taken after the theft. The heavy lookalike-address traffic around the attacker's wallets comes from third-party address poisoning campaigns.
How the theft could have been stopped
Bitget's 24 September notice says its security systems detected unauthorized transfers at 18:31 UTC, the minute of the first test transfers, yet attacker transfers kept being signed until 21:23:11. Looking back at the onchain record, the earliest signal a pre-signing check could have acted on came at 18:31:11, when Bitget 6 sent the 0.84 ETH test to an address with no history using a gas limit that wallet doesn't otherwise use for ETH sends. The controls below are written for exchanges, custodians and anyone else running hot wallets.
1. Bind every transfer to an independent record
The gap: By Bitget's account, the signer trusted an internal service to tell it the destination and amount.
Policy. Sign a hot-wallet transfer only if it matches a customer withdrawal record or a treasury allowlist entry held somewhere the requesting service can't write to. A compromised request path then can't create its own authority.
Monitoring and response. Reconcile signed transactions against the withdrawal ledger in real time, so a transfer with no matching record raises an alert within seconds.
2. Check parameters against what your pipeline would produce
The gap. Requests carried round gas limits that bypassed estimation, and nothing in the request path appears to have compared them with what the pipeline would have set.
Policy. Reject any request whose fields differ from the values your own pipeline would generate for it. On Bitget 6, the only native ETH sends with a 200,000 gas limit were the attacker's, so a check of this kind would have passed customer withdrawals and flagged the 0.84 ETH test at 18:31:11. Sub-threshold test transfers to never-seen addresses are worth an alert of their own.
3. Cap velocity on low-volume tiers
The gap. Low-volume warm wallets sent large transfers on five networks within nine seconds.
Policy. Set outflow limits per time window for each wallet tier and require a second approval above them. A warm-tier cap could have held back most of the $202.8M that left at 19:16, since $139.9M of it was a single XRP transfer.
4. Connect alerts to an automatic pause
The gap. Signing continued for 2h 52m after the first unauthorised transfer.
Monitoring and response. Wire any of the alerts above to pause the affected signer automatically, and give XRPL and Tron wallets the same monitoring as EVM wallets.
Screening & Intelligence. Screen the attacker addresses, which are labelled on Etherscan, and automate freeze decisions. The stablecoins on Ethereum had all been swapped into ETH within 31 minutes of the first large transfer, and none of the ~$88.3M in freezable assets that left Bitget was frozen on its original legs, so a freeze that waits for a manual review arrives after the assets have gone.
The wider pattern
The Bitget theft fits the pattern Hypernative described in Valid Signatures, Invalid Outcomes for Drift, Hyperbridge and KelpDAO: every signature was valid, and nothing checked whether what was being authorised should have been. Exchanges and custodians need to check each transaction against an independent record of what should be signed, before signing and continuously after.
Hypernative's Transaction Guard is built to check transactions before they're signed and executed, Onchain Monitoring & Automated Response to alert and act automatically when an unwanted or malicious transaction is executed onchain, and Screening & Intelligence to let bridges, issuers and exchanges screen counterparties against known attacker addresses.
Reach out for a demo of Hypernative's solutions, and follow Hypernative's blog and social channels for the latest on Web3 security. Secure everything you build, run and own in Web3 with Hypernative.
Proactive security for onchain finance. Website | X (Twitter) | LinkedIn
.avif)
