Cabinet
Back to Technology Insights
2026.09.25

About $387.5 Million Leaves Bitget Without a Stolen Key: The Transaction Data Fed to the Signing Approval Was Spoofed

About $387.5 Million Leaves Bitget Without a Stolen Key: The Transaction Data Fed to the Signing Approval Was Spoofed

What happened

According to Bitget's official security notice, the exchange detected unauthorized transfers from some hot wallets at 18:31 UTC on September 24, 2026, and activated emergency procedures. Bitget runs a three-tier wallet architecture of cold, warm and hot. It says the breach was confined to parts of the hot and warm layers and that cold wallets were untouched. Withdrawals were paused; deposits and trading continued.

The loss was announced in two steps. The first figure was about $351.6 million (about ¥55.28 billion). On September 25, after further on-chain tracing, it was revised to about $387.5 million (about ¥60.93 billion). Bitget says the $35.9 million increase came from Zcash and TRON transfers left out of the first count and does not reflect any new unauthorized movement. Reported affected assets include XRP, ETH, USDT, ZEC, USDC, USDT0, XAUt, BNB, AVAX and TRX.

TRM Labs notes that early on-chain estimates of $170–190 million counted only EVM chains. Another roughly $158 million left through the XRP Ledger and about $7 million through TRON, bringing the total close to Bitget's figure. Within hours, stolen ETH and XRP were split into fresh wallets, many holding round amounts of about 10,000 ETH or 20 million XRP. Part of the proceeds was swapped into BTC through THORChain.

On September 26, Bitget said the vulnerability had been identified and fixed and announced a phased restart of withdrawals:

  • September 28, 08:00 UTC: BTC
  • September 29: ETH
  • September 30: USDT
  • October 2: other assets and fiat

Mandiant and SlowMist are supporting the investigation. Bitget says the loss is covered by its User Protection Fund, which held more than $464 million at the time of the notice. The revised loss is about 84% of that figure.

How the attack worked: the approval input was broken, not the key

The technical core of this case lies in CEO Gracy Chen's explanation: "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 said the investigation had ruled out any leak of private keys. She also said the transfers were made from inside the system, without going through customer withdrawal requests. The technical evidence for the intrusion path has not been published, and the root-cause report promised within 24 hours had not appeared as of September 26.

The pattern matches the February 2025 Bybit theft. TRM Labs makes the same comparison: in both cases, what the approvers, human or automated, were shown was manipulated. At Bybit, cold wallet signers were led to approve false content. At Bitget, on the exchange's own account, the automated approval layer for hot and warm wallets processed spoofed data as legitimate transfers. In neither case was a key stolen.

The design question is whether the approval process simply trusted the data it received. Suppose the approval engine delegated the question "is this transfer legitimate?" to an upstream backend. Then once that upstream was compromised, the strength of the signing scheme stopped mattering. MPC, HSMs and multisig all exist to sign reliably what has been correctly approved. None of them exists to spot what should not have been approved. In this author's view, the question this incident raises is not how strong the key management was, but whether any independent path existed to verify the approval input.

On attribution, Chen called North Korean involvement "very likely," citing IP addresses linked to VPN services associated with a North Korean group. TRM Labs says the laundering network overlaps with the Bybit and AFX Bridge cases and points to TraderTraitor, but it has not made a definitive attribution.

What the three-tier design protected, and what it did not

The three-tier design appears to have done part of its job. Cold wallets were untouched, and the loss stayed within what the protection fund could absorb. The core purpose of tiering, which is to limit how much value can be signed online at any moment, worked.

At the same time, a single compromise inside the hot and warm tiers reached several chains and around ten assets at once. Reports put the outflow at 19 separate transfers. That suggests either the approval layer had no control on total value moved in a time window or on unusual concentration toward new destinations, or it had such controls but the spoofed data made the activity look normal. Which of these it was cannot be judged until the root-cause report is out.

Detection speed is the other question. Bitget says it responded immediately after detection, but it has not published the gap between the start of the outflow and detection. When assessing your own custody stack, the question is not only how many minutes it takes to halt withdrawals after detection. It is also whether you have a design limit on how many transfers, and how much value, can leave while the approval layer itself is compromised.

Pitfalls to watch

First, do not read "the keys are safe" as reassurance. In this class of incident, funds leave while the keys stay safe. If your threat model is built mainly around key theft, the same gap may exist in your systems.

Second, check what the loss figures cover. The early $170–190 million figures covered EVM chains only; with XRPL and TRON included, the real figure was roughly double. When you use on-chain estimates during incident response, always check which chains were counted.

Third, watch the withdrawal restart window. While an exchange reopens withdrawals in phases, stolen funds are more likely to reach other exchanges. TRM notes that proceeds tend to pass through bridges and cross-chain swaps and surface as deposits several hops away from tagged addresses. Screening that only checks the direct sender will miss them.

Fourth, treat the claim that the flaw is fixed with care. As of September 26, Bitget says the flaw is fixed but has not explained the intrusion path or the fix. What other firms can cite as grounds for their own controls is still limited to the summary: a backend compromise and spoofed transaction data. Until the root-cause report appears, treat it as a hypothesis rather than an established lesson. Even as a hypothesis, however, it is reason enough to audit your own approval path.

[Technical Insights & Actions]

  1. Signing infrastructure (MPC, HSM, multisig) signs whatever has been approved. If the approval input is spoofed, key strength is no defense. Bybit and Bitget were breached through different paths but at the same layer. [Product teams / Custody platform owners] Within the quarter, inventory whether both automated and human approvals include a step that reconstructs the transfer through a path independent of upstream systems (a separate ledger, re-decoding of the raw transaction) and checks it against the request.
  2. If a transfer that did not come from any customer withdrawal request passed approval, the approval layer was not checking which business record the transfer corresponds to. Matching withdrawals to business records should be an approval requirement, not an accounting task. [Product teams / Custody platform owners] By your next design review, require every hot and warm wallet transfer to link to an independently verifiable originating record (withdrawal ID or top-up instruction). Implement a policy that rejects, before signing, any transfer with no such link or that breaches amount limits or destination allowlists.
  3. After a large theft, proceeds reach other platforms via bridges and swap services, several hops downstream. Checking only the direct sender is not enough. [Integrators / Compliance liaison] For the coming weeks, including the restart window of September 28 to October 2, enable multi-hop deposit screening against addresses tagged "Bitget Exploiter September 2026" by TRM and others.

[Sources]

Note: JPY conversions use USD 1 = JPY 157.23 (Trading Economics, 2026-09-25).

This article is a technical commentary based on publicly available information and is not investment advice.

Next Article A "Block Validation Flaw" on Meter Mints Unbacked MTR and MTRG That Leak to BNB Chain via Passport: A Bridge Can Be No Safer Than the Source Chain's Validation