Bitget has revised the size of its September 24 breach upward and named a likely cause. In an incident explainer updated September 29, the exchange puts the affected amount at approximately $388 million across 12 wallet addresses, up from an initial estimate of $351.6 million that we reported in Bitget Lost $351.6M Without Anyone Stealing a Key. Bitget says the revision reflects a fuller accounting, including assets on Zcash and TRON, and not new theft after containment.
On the cause, Bitget says the attacker may have exploited a vulnerability in a third-party security product to obtain high-level internal credentials. Those credentials were then used to send fraudulent withdrawal commands to the wallet system, producing transfers that bypassed existing risk controls. Bitget says private-key compromise has been ruled out, cold wallets were unaffected, and it has notified the vendor and disabled the affected functionality pending a fix. It has revoked and reissued internal credentials and now requires multiple approvals for critical operations. Mandiant and SlowMist are supporting the investigation. Bitget describes this as a preliminary finding, and the vendor is not named.
Why it matters
If the account holds, the entry point was a security tool, the kind of product organizations deploy to reduce risk. It follows the pattern we described in Attackers Are Targeting the Consoles That Secure You, where management and security infrastructure holds standing privilege.
One original angle
Bitget’s own timeline shows detection worked at the ledger level: reconciliation flagged a discrepancy 34 minutes after the first transfers and withdrawals were blocked. The failure sat upstream, where a stolen credential could issue commands the wallet system trusted. Multi-approval for sensitive actions is the fix Bitget chose, and any team with a security product holding high-level credentials should ask whether one credential there can authorize one consequential action alone.
Source: Bitget
