Bitget's own approval process moved out $388 million on spoofed transaction data

A Bitget customer who logs in after the theft sees the same balance as before. Chen has told customers their balances remain accurate and that the whole loss sits inside Bitget's User Protection Fund, which she valued at more than $464 million ^[4]. That customer can still deposit and trade. They cannot withdraw while a security review runs ^[5]. Paying for the loss would use up at most about 84 percent of the fund ^[13].

Here's what custody teams tell themselves: if the keys are safe, the money is safe. At Bitget, the keys were safe. Its cold wallets were not hit, and the breach reached only parts of the hot and warm wallet layers ^[2]. Chen described the route the attacker actually took on X. "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," she wrote ^[8]. Gizmodo summarised it this way: the payouts looked legitimate to Bitget's internal system ^[9].

In Chen's account, the approval step acted on false data from a system the attacker already controlled ^[8]. That account comes from Bitget alone. The company has not said which backend system was compromised or how the attacker reached it, and Mandiant and SlowMist are still helping with the investigation ^[10].

Bitget's first loss figure was $35.9 million short, and the revision added about 10 percent to it ^[12]. The public token breakdown came from the on-chain tracker Lookonchain, which put 102.93 million XRP, worth about $157.48 million, at the top of the list ^[14]. That one token is about 41 percent of the revised total ^[20].

A team that runs automated payouts can sort each of its approval paths on a 2x2. One axis asks whether the system that requests a payout can also write the data the approver checks. The other asks whether approval releases funds with no offline step. Where both answers are yes, you have the case Chen described: one compromised backend supplies the evidence and receives the money. If the requester writes the data but release needs an offline step, that step is the last check left. If the approver reads a record the requester cannot touch, such as the chain itself or a separate ledger, an attacker has to take over two systems before funds move. Independent data plus offline release is the slowest box and the hardest to rob.

I'd fix the paths where both answers are yes first. Pointing hot-wallet approvals at an independent record means an extra lookup, and a little more delay, on every withdrawal customers make.