Most exchange heists still get told as a private-key story: a hot wallet's signing key leaks or gets phished, and the funds move. Bitget's account of its own breach, covered by The Hacker News, is a different shape of failure. The attacker compromised a critical backend system sitting inside the wallet infrastructure, used it to spoof transaction data, and triggered the authorisation process into approving transfers it should never have approved. No key was stolen, because none needed to be - the system that was supposed to check the transaction believed the transaction was legitimate.
Cold storage did its job. The authorisation layer didn't
Bitget has been at pains to draw this distinction, and it's a fair one: cold wallets and the large majority of platform assets were never touched. What failed sat one layer up from custody - the backend logic that decides whether a requested transfer gets signed and released at all. BleepingComputer's reporting on the incident describes withdrawals being suspended platform-wide out of caution while Bitget runs what it's calling a comprehensive security review - the standard response when you don't yet know whether the specific hole you found is the only one.
The North Korea pattern, again
Bitget says its own analysis of IP behaviour and on-chain movement of the stolen funds is "highly consistent with known patterns" of North Korean state-linked operations - the same attribution that's followed a long run of exchange breaches this year. TechCrunch notes this is already the largest crypto theft of 2026, ahead of a $340 million hack the previous month where the attacker eventually returned all but $47 million - there's no indication here that any of the $351.6 million is coming back. CNBC's coverage adds that Bitget's User Protection Fund, holding roughly 5,500 BTC worth around $464 million, will cover the full loss to customers - a reserve that happened to be sized generously enough to absorb a hit of exactly this scale.
Why this matters beyond one exchange
The interesting failure here isn't that an exchange got breached - it's which control got bypassed. Backend authorisation logic that decides whether a transaction is legitimate is, functionally, as sensitive as the private key it's protecting, because an attacker who can make that logic say yes never needs the key at all. Exchanges and any enterprise treasury function holding meaningful digital asset exposure are, in effect, running a second custody model - the software that decides when to release funds - that gets far less scrutiny than the keys themselves.
- Treat transaction-authorisation and approval logic as a control with the same sensitivity as private key custody, not as ordinary backend application code - it deserves the same segregation, monitoring and change control.
- Don't assume an attacker needs your keys to move your funds - build detection for spoofed or anomalous internal transaction data reaching the authorisation layer, not just for key exfiltration.
- Size any reserve or insurance fund against a worst-case hot-wallet-and-warm-wallet loss scenario specifically, rather than a generic percentage of assets under management - Bitget's fund happened to cover this loss; not every exchange's would.
- If your organisation holds digital assets on a third-party exchange or custodian, ask directly how authorisation logic is isolated from the systems an external attacker could plausibly reach first.
Bitget's cold storage held because cold storage is the part of this model everyone already scrutinises. The part that failed is the part that usually doesn't get audited with the same rigour - and on current form, North Korean state-linked groups are finding that gap faster than the industry is closing it. Email sales@halfteck.com if you'd like a second opinion on how your own organisation's digital asset exposure is governed.