Bitget Says Its Keys Were Never Stolen. The $387.5M Hack Exposes a Bigger Custody Problem

At 18:31 UTC on September 24, Bitget says its security systems detected unauthorized transfers leaving some of the crypto exchange's hot wallets.

But the money did not immediately stop moving.

An on-chain reconstruction by Bitquery traced 21 transfers and found the final one left a Bitget wallet at approximately 21:23 UTC. If the two timelines are compared directly, the exchange's own wallets were still sending assets to attacker-controlled addresses 2 hours and 52 minutes after Bitget says the incident was detected.

By the following day, Bitget's initial estimate of $351.6 million had grown to $387.5 million after investigators identified additional Zcash and TRON assets that were not included in the first accounting. Bitget stressed that the increase represented better tracing of the original incident, not a second attack. Bitget's updated security disclosure lists XRP, ETH, USDT, ZEC, USDC, USDT0, XAUt, BNB, AVAX and TRX among the affected assets.

The size makes the breach significant. The mechanism makes it more important.

According to Bitget CEO Gracy Chen, the attacker did not obtain the private keys controlling the affected wallets. Instead, Chen said a critical backend component inside Bitget's wallet infrastructure was compromised, allowing the attacker to spoof transaction data and trigger the exchange's authorization process.

In other words, if Bitget's account is accurate, the attacker did not steal the key to the vault.

The attacker manipulated the instructions being presented to the system that held the key.

That distinction exposes a broader problem in digital asset custody. Protecting cryptographic keys is not enough if an attacker can compromise the software responsible for deciding what those keys are allowed to sign.

What was actually stolen

Bitget's latest official accounting says approximately $387.5 million was transferred to attacker-controlled addresses. The company confirmed the affected assets were XRP, ETH, USDT, ZEC, USDC, USDT0, XAUt, BNB, AVAX and TRX. Bitget has not publicly provided a final per-asset breakdown for the full $387.5 million, particularly the newly identified Zcash portion. Bitget

Independent blockchain analysis provides considerably more detail. Bitquery reconstructed 21 transfers from Bitget-controlled wallets across eight networks and valued the transfers it could trace at approximately $357.36 million at transaction-time prices. Its figure differs from Bitget's final $387.5 million because Bitget subsequently added further Zcash and TRON assets to its accounting.

The amounts above come from Bitquery's transaction-by-transaction reconstruction and should therefore be described as independently traced quantities, rather than Bitget's official per-asset accounting.

What apparently happened inside Bitget

A centralized exchange normally separates crypto storage into layers. Hot wallets remain connected and provide liquidity for routine withdrawals. Warm wallets create another operational layer between hot storage and cold wallets. Cold wallets are kept substantially isolated from online infrastructure.

Bitget says only parts of its hot and warm wallet infrastructure were affected and that its cold wallets remained secure. Its separate self-custodial Bitget Wallet product was also unaffected because it runs on different infrastructure, according to statements provided to The Block's reporting on the incident.

But key storage is only one component of a custody system.

Before a legitimate withdrawal reaches a private key or signing service, another system has usually already decided the destination address, asset, amount, network and whether the transaction satisfies internal policies.

Bitget's explanation indicates that this upstream process was manipulated.

Chen said the attacker compromised a wallet backend, spoofed transaction data and caused Bitget's normal authorization mechanism to process the transfers. CoinDesk reported Chen's explanation, including her statement that private-key compromise had been ruled out.

A simplified version of the apparent failure looks like this:

That means calling the event simply a "blockchain hack" would be misleading. There is currently no evidence that the cryptography of Ethereum, XRP Ledger or the other affected blockchain networks failed.

The apparent failure occurred in the custody and authorization infrastructure sitting above those networks.

The 172 minutes Bitget still needs to explain

Bitget's first security notice says unauthorized activity was detected at 18:31 UTC and that emergency response procedures were activated "within minutes."

Bitquery's reconstruction provides a more complicated picture.

Bitquery also found characteristics that differed from normal customer withdrawals. Seven transactions from Bitget Ethereum hot wallets used fixed gas limits of 100,000 or 200,000, settings that Bitquery said had not appeared in customer withdrawals from those wallets during the previous week.

None of this establishes that Bitget failed to respond after discovering the breach. Detecting suspicious activity is different from immediately understanding which systems are compromised, and shutting down a multi-chain wallet infrastructure can itself require controlled intervention.

But it leaves an important unanswered question.

Once Bitget knew unauthorized transfers were occurring, why could the compromised transaction path apparently continue producing transfers for almost another three hours?

That question matters because containment is part of security architecture. Preventing the first compromise is one problem. Preventing a compromised component from draining hundreds of millions before it can be isolated is another.

Bitget says it knows the attack path, but the public still does not

By September 25, Bitget said its investigators had identified the attack path, understood how existing security controls were bypassed and remediated the underlying vulnerability. Independent cybersecurity firms Mandiant and SlowMist are assisting the investigation.

What Bitget has not yet publicly explained is how the attacker initially entered that backend system.

There is no publicly established answer showing whether the entry point involved compromised employee credentials, a developer workstation, malware, social engineering, an exposed administrative system, vulnerable software, a supply-chain compromise or another technique.

That distinction is critical.

A flaw unique to Bitget would have one set of implications. A weakness in commonly used wallet software, custody infrastructure or operational processes could expose other exchanges and custodians.

There is also a transparency issue still developing. Bitget's original notice said a full incident report including root-cause analysis and corrective actions would be published within 24 hours. A subsequent withdrawal service notice said the complete incident report would be published within 24 hours after withdrawals are restored.

As of September 27, Bitget has disclosed substantially more about the mechanism, but a full independent technical postmortem explaining the initial compromise has not been published.

That report is now one of the most important outstanding pieces of the incident.

Who was behind the Bitget attack?

North Korean involvement is the leading theory, but it should not yet be reported as an established government attribution.

Chen has said involvement by a North Korean group is "very likely." According to TRM Labs' investigation, Bitget's preliminary investigation identified IP addresses associated with VPN services previously connected with a North Korean hacking group.

Blockchain intelligence firm Elliptic goes further. It assesses the Bitget attack as highly likely to be DPRK-linked, citing overlaps between infrastructure used to move Bitget funds and infrastructure associated with earlier North Korean-linked thefts, including the 2025 Bybit attack. Elliptic also points to the rapid conversion of stablecoins and tokens into native cryptoassets and the use of cross-chain laundering routes as consistent with techniques it has documented in previous DPRK operations. Elliptic's Bitget analysis says the incident would take suspected North Korean crypto theft tracked by the company above $1 billion in 2026.

TRM Labs is more cautious.

Its researchers found connections between the Bitget proceeds and laundering infrastructure previously associated with attacks including Bybit and AFX Bridge. TRM says it has not observed that laundering network being used for another hacking group's thefts. But it explicitly states that it has not definitively attributed the Bitget intrusion to North Korea.

That difference matters.

The blockchain can reveal where stolen funds travel. It can establish relationships between wallets and previous transactions. It cannot, by itself, prove who was sitting behind the keyboard when Bitget's backend was compromised.

Unlike the Bybit breach, which the FBI formally attributed to North Korea's TraderTraitor activity in February 2025, the sources reviewed by TDisrupt show no comparable public government attribution for Bitget as of September 27.

For now, the defensible conclusion is suspected DPRK-linked attackers, supported by significant circumstantial and blockchain intelligence, but not yet conclusively attributed by public authorities.

The money started moving almost immediately

The laundering behavior also provides clues about the operation.

TRM found stolen ETH and XRP divided across newly created wallets, often in unusually round amounts. Several Ethereum wallets received about 10,000 ETH each, while XRP was divided among accounts containing roughly 20 million XRP.

Some proceeds began crossing networks through infrastructure including THORChain, Chainflip, Across and other services before portions were converted into Bitcoin.

Bitquery separately traced stolen BNB and TRX through cross-chain routes and had identified approximately 126.71 BTC paid out from those flows by September 25.

The strategy serves two purposes. It reduces exposure to assets that issuers can freeze and makes tracing increasingly complex as funds move through multiple chains, intermediary wallets, and conversion services.

That has already affected recovery.

Circle and Tether were able to blacklist approximately $318,000 in USDC and USDT associated with one attacker wallet because their stablecoin contracts contain centralized freezing mechanisms. CoinDesk's analysis of the freeze shows why this has limited reach: token issuers can't freeze native assets such as ETH.

XRP creates a similar problem.

Nearly 103 million XRP was taken during the incident. By September 26, approximately $83 million worth of stolen XRP had already left three of the original holding wallets, according to CoinDesk's review of XRP Ledger transactions. Roughly $75 million remained across the original accounts at the time of that analysis.

Ripple cannot blacklist native XRP held in a self-custodied wallet. An exchange receiving the stolen XRP can potentially block the attacker's account when the funds arrive, but the XRP Ledger itself does not provide Ripple with an issuer-style freeze switch for XRP.

This makes the recovery effort a race between blockchain intelligence and laundering infrastructure.

Bitget has responded with containment, tracing and a bounty

Bitget suspended withdrawals after detecting the incident, flagged attacker addresses, contacted law enforcement and brought in Mandiant and SlowMist. Deposits and trading remained available.

The exchange has also created a recovery bounty system. Under its Recovery Bounty Program, eligible parties whose voluntary actions directly result in funds being frozen can receive 5% of the amount frozen. Similar assistance that directly recovers assets can qualify for a 5% recovery bounty. Bitget is also using Bybit's LazarusBounty initiative as a channel for the effort.

Bitget says its User Protection Fund, valued above $464 million before the incident, is sufficient to absorb the loss and that customer account balances remain intact.

Withdrawals are scheduled to return gradually rather than simultaneously. According to Bitget's restoration schedule, Bitcoin withdrawals are due to restart at 08:00 UTC on September 28, followed by ETH on September 29, USDT on September 30 and remaining tokens, fiat and P2P services on October 2.

Chen is also scheduled to hold a public AMA at 07:30 UTC on September 28, shortly before the first withdrawal reopening.

Those milestones will test Bitget's claim that the compromised path has been fully eliminated.

This pattern has appeared before

What happened at Bitget is not identical to previous exchange attacks. But it belongs to an increasingly important class of custody failure where attackers target the decision and authorization layer around the signer, rather than simply stealing the private key.

The Bybit attack is the clearest comparison.

During the February 2025 incident, attackers compromised credentials belonging to a Safe developer and gained access to Safe infrastructure. Bybit's forensic update said the attacker was able to deceive signers into approving a malicious transaction.

Later technical analysis found malicious JavaScript had been injected into Safe's infrastructure and targeted Bybit's wallet specifically, changing transaction parameters behind the interface while preserving what appeared to be legitimate information for the signers. Check Point's technical reconstruction describes how recipient and operation parameters could be altered while the displayed transaction retained a legitimate appearance.

The FBI subsequently attributed the $1.5 billion theft to North Korea.

WazirX provides another comparison, although responsibility for the exact technical failure remains disputed.

After more than $230 million was stolen in July 2024, WazirX's preliminary report said there was a discrepancy between transaction information shown through Liminal's interface and the transaction that was actually signed. WazirX suspected that the payload had been replaced in a way that transferred control of the multisig wallet.

Liminal rejected the claim that its infrastructure had been compromised and argued that the incident occurred at the customer level. Liminal's response said its own platform, infrastructure and assets remained secure.

The competing explanations should not be collapsed into a settled technical conclusion. What is relevant is that, as with Bybit and now Bitget's own description, transaction intent and what an authorization system believed it was approving became part of the attack surface.

CoinEx shows the older and more familiar model. Its official investigation into the September 2023 attack preliminarily attributed that incident to leakage of hot-wallet private keys.

That difference is important.

In a key-compromise attack, the security objective is relatively clear: prevent the attacker from obtaining the signing secret.

In an authorization-layer attack, the private key can remain exactly where it belongs and still produce a malicious transaction.

The custody problem is moving upstream

The crypto industry's security model has spent years focusing on key protection.

Hardware security modules, cold wallets, multisignature systems, threshold signatures and air-gapped devices are all designed, in different ways, to make unauthorized signing difficult.

But all of those systems eventually face the same question:

What exactly are they being asked to sign?

If the transaction builder, withdrawal service, policy engine, administrative interface or authorization backend is compromised, a highly protected key can become the final executor of an attack rather than the barrier preventing it.

This is why independent verification of transaction intent is becoming critical.

The system constructing a transaction should not be the sole system trusted to describe that transaction to its approver. High-value custody infrastructure increasingly needs independent transaction simulation, destination verification, transaction-value limits, cross-chain anomaly detection, rate controls and circuit breakers that operate outside the same control plane as the wallet backend.

The lesson from Bybit was similar. Safe's subsequent security research has argued for reducing dependence on a single wallet interface and separating components such as transaction queues, signers and cosigners so that transaction intent can be independently verified. Safe's research on moving trust beyond the wallet UI describes the wallet as several cooperating security components rather than a single application.

Bitget may now provide the centralized-exchange version of the same warning.

Could the same attack happen elsewhere?

Not necessarily through the exact vulnerability used against Bitget. That vulnerability has not been publicly documented.

But the class of attack is portable.

Any exchange, custodian, treasury platform, bridge or institutional wallet system where the signing infrastructure trusts transaction information generated by an upstream system can potentially face the same fundamental problem.

An attacker does not always need to defeat cryptography.

They can attack the people and software that decide how cryptography gets used.

That may mean compromising a transaction-building service. It may mean obtaining developer access. It may mean manipulating an administrative interface. It may mean supply-chain compromise, social engineering or malware.

Which of those happened at Bitget remains unanswered.

Until the full root-cause analysis is published, claiming one would go beyond the available evidence.

What happens next matters more than the first headline

The immediate financial question is whether Bitget can absorb the loss without creating a customer shortfall. The exchange says it can, pointing to its Protection Fund and stating that customer balances remain intact.

The security question is harder.

Bitget needs to explain the initial compromise, which systems the attacker controlled, how transaction data reached the signing infrastructure, what independent verification existed, how those controls were bypassed and why unauthorized transfers apparently continued after the exchange says it detected the incident.

It also needs to explain what has materially changed before the withdrawal system goes back into production.

The attribution question remains open as well. Blockchain intelligence firms have produced substantial evidence pointing toward North Korean-linked infrastructure and methods, but this is not yet the same as the FBI's formal attribution of the Bybit attack.

And then there is the money.

Large portions of the stolen assets are outside the control of stablecoin issuers and continue to move across networks. If the laundering behavior follows patterns documented after previous DPRK-linked attacks, investigators may be tracing these assets for months or years rather than days.

The Bitget breach therefore exposes something broader than one exchange's security failure.

The blockchain industry has spent years learning how to protect private keys.

The next security problem is making sure those keys can independently determine whether the instructions reaching them are true.

That problem has already appeared at Bybit. A related dispute sat at the center of WazirX. Bitget now says hundreds of millions of dollars left its own infrastructure while its private keys remained uncompromised.

If that account survives independent scrutiny, the most important question from the $387.5 million Bitget hack will not be who stole the keys.

It will be who controlled what the keys were told to sign.