Cryptocurrency exchange Bitget lost roughly 388 million dollars from hot and warm wallets on 24 September 2026, across 12 addresses on 11 blockchains. Its own incident page is unusually specific about the clock: unauthorised transfers at 18:31 UTC, a reconciliation system flagging the discrepancy at 19:05, and the root cause identified at 08:43 the following morning.

Cold wallets were not touched, and Bitget says private-key compromise has been ruled out. That matters for what this was: not a cryptography failure, and not a wallet failure. A credential failure.

The product that was supposed to be the control

Bitget's wording is careful, and worth reading as written: the attacker "may have exploited a vulnerability in a third-party security product to potentially obtain high-level internal credentials".

Investigations by Mandiant and SlowMist are reported to go further. Access is dated to 31 August, three and a half weeks before the money moved. A web shell was placed on one of two compromised security appliances, command-and-control was established, and the intruders moved laterally to the production wallet job server, where a purpose-built withdrawal tool issued the transfers.

The uncomfortable part is which box was the entry point. A security appliance is deployed with privileged visibility into traffic and often into credentials, it sits where it can see everything, and it is frequently the one system a security team does not treat as an ordinary application with an ordinary patch cycle. Compromising it is not a step around the controls. It is a step into them.

The withdrawals were valid

Nothing in the published accounts describes a control being bypassed in the technical sense. The transfers were issued with high-level internal credentials by a tool built for the purpose, and the wallet system did what it is designed to do with a correctly authorised instruction.

That is why detection came from reconciliation rather than from prevention. The thirty-four minutes between the first transfer and the flag is the honest measure of this architecture: the checks that mattered were the ones comparing what left against what should have left, not the ones deciding whether the instruction was allowed.

The numbers do not agree

Published figures for the loss vary. Bitget's own page gives approximately 388 million dollars and describes it as the latest reconciliation of transactions associated with the incident. Other reporting has used 387.5 million, and at least one account has put the figure at 351.6 million.

Treat any single number as provisional until the promised forensic report lands. On-chain losses get revised as addresses are attributed, and an exchange counting its own hot wallets has a different view from an analyst counting outbound transactions.

Bitget's chief executive has attributed the attack to North Korean operators on the basis of address patterns and on-chain analysis. That attribution is the company's, not a government's, and it is the kind of claim that usually takes longer to confirm than to make.

Hot, warm, cold, and what each one costs

The three wallet tiers are an exchange's main risk control, and this incident is a clean demonstration of what they do and do not buy.

Hot wallets sign automatically so that withdrawals complete in seconds. Warm wallets sit behind more process but still sign without ceremony. Cold wallets are kept offline, and moving anything out of them requires people and time. Every exchange trades customer convenience against the size of the balance an attacker can reach, and the split decides how much a bad day costs.

Here the split worked exactly as designed. The attacker reached the tiers that sign on instruction and took what was in them. Nothing was taken from cold storage, and Bitget says private keys were never compromised — which is consistent with a theft carried out through the systems that ask the wallets to sign, rather than through the key material itself.

Solvency was a decision made earlier

Bitget says customer balances are unaffected and the loss falls on its protection fund, and it resumed withdrawals in stages: Bitcoin on 28 September, Ether on the 29th, USDT on the 30th.

Both of those were possible because of choices made before the incident. A reserve that can absorb a nine-figure loss has to exist in advance, and a withdrawal queue that can be paused and reopened asset by asset has to be built that way. The alternative, which this industry has seen repeatedly, is an exchange that halts everything, discovers it cannot cover the gap, and converts a security incident into an insolvency.

What to do

  • Patch and monitor security appliances on the same schedule as internet-facing applications. The privileged position that makes them useful is the same thing that makes them worth attacking.
  • Separate the credentials a monitoring or security product holds from the credentials that can authorise movement of funds or data.
  • Make reconciliation a control, not a report. Bitget caught this in thirty-four minutes because something was comparing expected against actual.
  • Rehearse the pause. Phased resumption of withdrawals, as Bitget did from 28 to 30 September, is only possible if somebody has decided in advance what can be stopped and in what order.

What is not established

  • The vendor and the product, which Bitget has not named.
  • Whether the flaw used against it was genuinely unknown to the vendor at the time.
  • The final loss figure, which the published accounts disagree about.
  • The attribution. It rests on the company's own analysis of addresses and infrastructure.
  • Whether the two compromised appliances were breached the same way.