The Bitget Breach: How $388 Million Left Without a Stolen Key

On 24 September 2026 at 18:31 UTC, someone made two small transfers out of Bitget. Both were deliberately sized to stay under the exchange's risk-control threshold. Neither raised an alert.

Thirty minutes later the large transfers began. By the time they stopped, roughly $388 million was gone, making it the largest crypto theft of the year.

No private key was stolen. No smart contract was exploited. Cold storage was never touched.

What an exchange's wallet architecture looks like

Exchanges split customer funds across three tiers:

Cold wallets hold the bulk of the assets. The keys live offline, often on hardware in a vault, and moving anything requires a deliberate physical process with multiple people. Slow by design.

Warm wallets sit in the middle. Connected, but with tighter controls and larger approval requirements.

Hot wallets hold the working balance. They are online and automated because a customer clicking "withdraw" at three in the morning expects the money to move without a human waking up.

Around this sits a risk-control layer: automated rules that watch outgoing transfers and block or escalate anything unusual. Too large, too fast, too many, wrong destination.

Bitget's cold wallets were not breached. That part of the architecture did exactly what it was built to do. The attacker never needed it.

How they got in

Per Bitget CEO Gracy Chen, the attacker exploited a zero-day vulnerability in a third-party security product the exchange was using. A zero-day is a flaw with no patch available, unknown to the vendor at the time it is used.

Bitget has not named the product.

That flaw gave the attacker access to an internal management system. From there they obtained legitimate high-level credentials, and this is the part that matters most: from that point forward, everything they did was authorized.

Chen's account states the attacker disguised their activity as routine administrative operations and removed traces of their actions as they went.

Why the wallet system did what it was told

Once inside, the attacker inserted fraudulent withdrawal commands into the wallet-related backend services. They arrived from an internal management system, carried valid credentials, and looked like routine administration.

The two small transfers at 18:31 UTC are the most revealing details in the incident. They were test shots, sized to sit below the risk-control threshold. The attacker was confirming two things: that the commands would execute, and where the alerting line sat.

Thirty minutes later, knowing both, they finally moved the money. The wallet system executed the transfers and the risk controls were bypassed.

The assets

Ether, USDT, USDC, AVAX and BNB were among the transferred assets, taken from hot and warm wallet infrastructure.

The XRP is the part worth following, because it is where the recovery story falls apart.

Nearly 103 million XRP was taken across five accounts. Two accounts that each held 20 million XRP were subsequently drained down to about 23 and 55 tokens respectively. Roughly $83 million in XRP was moved out of three holding wallets within two days.

The freeze that was not available

When a large theft happens, the standard hope is that issuers freeze the stolen assets before they can be laundered. That hope depends entirely on whether a freeze switch exists for the asset in question, and for XRP it does not.

The XRP Ledger does have a freeze capability. It lets an issuer freeze tokens issued on the ledger. It does not extend to XRP itself, the ledger's own native asset. Ripple has no built-in way to stop the attacker from spending those coins.

About $75 million in XRP sits in accounts that cannot be frozen under the network's existing rules. Exchanges can restrict the accounts that receive them, but nobody can freeze coins sitting in a wallet the attacker controls.

Circle and Tether did freeze stolen stablecoins, because USDC and USDT carry blacklist controls at the issuer level. The amount they were able to freeze was approximately $320,000.

Set those two numbers next to each other:

That is 0.08%.

The freeze capability that gets cited as a safety net for exactly this scenario recovered eight hundredths of one percent, and only on the assets that had a centralized issuer willing and able to pull a lever.

What Bitget has done since

The vulnerability has been patched. Bitget states that losses will luckily be fully covered by its User Protection Fund, which holds 5,500 BTC. Additionally, a bounty program offers 5% of successfully frozen funds to anyone assisting recovery.

Withdrawals were suspended and are being restored in stages:

Bitget suspects a group previously identified with North Korean connections. TRM Labs has identified overlaps pointing to the group known as TraderTraitor. Formal attribution is pending Bitget's own incident report, so treat it as a suspicion rather than a finding.

What an operator should take from this

Your security vendors are part of your attack surface. A product installed to reduce risk was the way in. Vendor software typically runs with high privileges, sits inside the trust boundary, and is rarely modeled as a threat by the team that installed it, although it should be.

An authenticated command is not a verified command. Every check in the chain passed because the attacker held valid credentials. Controls that require something beyond authentication, a second independent approval on a separate system, or a hard cap that no single credential can raise, are what stand between a compromised credential and a total loss.

Small transfers below your alerting threshold are a signal, not noise. Two transactions specifically sized to sit under the limit, thirty minutes before a large withdrawal, form a recognizable pattern. Alerting configured only on size would never see it. Alerting on unusual sequences would.

Know which of your assets can actually be frozen. The answer differs by asset and most operators have never checked. Centrally issued stablecoins have a switch. Native chain assets generally do not. If your incident response plan assumes recovery through freezing, it works for a fraction of your book and you should know which fraction before you need it.

Cold storage protects against the wrong failure here. Bitget's cold wallets held perfectly and it made no difference, because the attack never went near them. The hot and warm tier is where the automation lives, and automation is where an authorized command becomes money out the door.

Securing the unseen

The security industry these days spends most of its attention on code. Audits look at contracts. Bug bounties pay for vulnerabilities in protocols. Formal verification proves properties about programs.

Every one of those would have passed here.

The contracts were fine. The keys were fine. The cryptography was fine. The cold storage was fine. What failed was a vendor product nobody was auditing, a credential that carried more authority than it should have, and a risk control that measured the size of a transfer without asking why an administrator was suddenly making one.

Learn more at 0xhades.io/research