Bitget lost $387.5m without anyone stealing a private key
Serguey Asael Shinder2 min readBitget has confirmed a $387.5 million breach detected on 24 September. The mechanism is the part that matters: attackers spoofed transaction data to trigger legitimate-looking transfer approvals out of the exchange's hot and warm wallets. They did not steal private keys. The reported haul includes roughly 103 million XRP, about $157 million. CEO Gracy Chen says IP addresses and on-chain indicators resemble North Korean activity. Reporting by Jose Antonio Lanz for Decrypt, edited by Guillermo Jimenez.
What it means
Read that sequence again, because it inverts how exchange risk is usually discussed. The keys held. The signing infrastructure did what it was asked. What failed was the process that decides what to ask it - an internal transfer request was forged convincingly enough that the approval path treated it as routine. That is not a cryptography failure and no amount of key custody hardening addresses it. A multi-signature scheme where every signer is looking at a spoofed request produces a perfectly valid signature over a theft.
It puts the attribution question in its proper place, too. Whether Pyongyang is behind it is significant for policy and for fund recovery, and irrelevant to the lesson: the attack is available to anyone who can forge internal transfer traffic. The North Korea angle also tends to absorb the coverage, because a nation-state adversary is a more comfortable explanation for an exchange than "our approval workflow trusted its own inputs".
The XRP concentration is the operational detail with consequences today. About $157 million of a single asset is large enough that its movement is trackable and its liquidation detectable, which is exactly why other issuers have been freezing addresses in adjacent incidents this week - and it will be the test of how much of this is recoverable. For everyone else running an exchange or a treasury, the check this incident asks for is narrow and unglamorous: what independently verifies that an internal transfer request is genuine before a signer sees it? If the answer is "the system that generated it", the same attack works.