How much was stolen in the Bitget hack?

Bitget's official incident page, last updated October 4, 2026, gives a final verified figure of approximately $388 million transferred out, involving 12 hot and warm wallet addresses. Earlier estimates were about $351.6 million and about $387.5 million.

What is a pre-broadcast control layer?

A pre-broadcast control layer independently evaluates every outbound crypto transfer before it is signed or broadcast — checking destination, amount, velocity, and required approvals — and can hold or block it, regardless of what upstream systems have approved.

Outdated — notice added October 4, 2026. We published this analysis on September 26, 2026 from early press reports, and we no longer update it. Bitget has since published its root cause and final figures on its official incident page (last updated October 4, 2026). Where the two differ, Bitget's page supersedes this one. We have corrected the figures and root-cause statements below to match it. For the current control analysis, see Pre-Signing Transaction Verification.

CryptOps Research · Incident Analysis

Anatomy of the Bitget Heist: When the Approval System Is the Attack Surface

Q: Were Bitget's private keys stolen?

No, according to Bitget's incident page. Bitget says attackers exploited a zero-day vulnerability in a third-party security product to steal internal credentials, then wrote forged withdrawal commands directly into the wallet system, which processed them as normal withdrawals and bypassed risk control verification. Bitget states that private keys were not compromised and cold wallets were unaffected.

By Tarik Zahedi · Published September 26, 2026 · Outdated notice and corrections added October 4, 2026 · No longer maintained

On September 24, 2026, attackers moved approximately $388 million out of Bitget's hot and warm wallets (Bitget's final verified figure). Bitget says the attackers did not steal private keys. Instead, they wrote forged withdrawal commands directly into the wallet system, which processed them as normal withdrawals and bypassed risk control verification. The lesson for every crypto treasury: controls that live inside the same system as the approvals can fail together. An independent gate before broadcast is the last line of defense.

What happened

Bitget says its security system detected unauthorized transfers involving certain hot and warm wallets at 18:31 UTC on September 24. The company paused withdrawals, and Mandiant and SlowMist are assisting with the investigation. In its October 4 update, Bitget gives a final verified figure of approximately $388M, involving 12 wallet addresses, all of them hot or warm wallets. Cold wallets were unaffected. Bitget lists the affected assets as XRP, ETH, USDT, ZEC, USDC, USDT0, XAUt, BNB, AVAX and TRX, across Ethereum and multiple EVM networks, the XRP Ledger, Zcash and TRON.

In September, press reports quoted Bitget as saying that preliminary evidence, including IP patterns tied to VPN services previously used by a North Korean group and on-chain behavior, pointed to North Korean attackers. Bitget's October 4 incident page does not address attribution. Elliptic reported links between some of the stolen funds and addresses tied to earlier hacks, including Bybit's in 2025. It estimated that the attack pushed North Korea's crypto thefts past $1 billion for 2026.

Confirmed vs. still under investigation

Item	Status
Unauthorized transfers from hot and warm wallets; cold wallets unaffected	Reported by Bitget
Loss size: approximately $388M, 12 wallet addresses (Bitget, final verified figure, October 4). Earlier estimates: ~$351.6M initial; ~$387.5M revised.	Final figure (Bitget)
Private keys not compromised; cold wallets unaffected	Bitget incident page
Intrusion method: a zero-day in a third-party security product used to steal internal credentials, then forged withdrawal commands written directly into the wallet system, bypassing risk control verification. Traces were later deleted.	Bitget incident page
Formal security report with full technical details	Not yet published
North Korean attribution	Suspected, not formally confirmed

Why this one matters

Most treasury security thinking focuses on keys: who holds them, how they are split, where they are stored. Bitget's account points to a different failure mode. If the attacker can write withdrawal commands below the risk checks, key security never gets tested. The wallet processes each transfer as a normal withdrawal.

If the press reports are correct, this fits a broader pattern. North Korean groups have increasingly targeted the people and processes around the keys: fake recruiters, fake investor pitches to executives, insiders placed through IT hiring, and signer compromise staged over weeks. The target is the approval path, not the vault.

The control lesson: a gate that doesn't trust upstream

An independent pre-broadcast layer evaluates every outbound transfer on its own terms, regardless of what upstream systems approved. For the pattern reported here, transfers from hot and warm wallets to destinations outside normal flows, several independent checks are designed to fire:

Velocity. Many large outbound transfers in a short window exceed normal treasury behavior and trigger a hold.

New destination. Transfers to addresses not on an allowlist are held for verification rather than cleared.

Amount thresholds. Transfers above set limits require additional, separate approvers.

Out-of-band dual control. A second approval, collected outside the compromised system, is required before broadcast.

Audit trail. Every decision is logged with who, what and why, so incident response starts with facts.

We don't know Bitget's internal architecture, and we are not claiming any specific product would have prevented this incident. The point is structural: controls that share a failure path with the approval system can be bypassed together.

Five questions every treasury should answer this week

If our internal approval system were compromised, what would stop an outbound transfer?
Are velocity limits enforced outside the system that initiates transfers?
Can funds go to a never-seen address without separate verification?
Is our second approval collected through an independent channel?
Could we reconstruct every approval decision within an hour of an incident?

See the pattern in action

We built a simulation modeled on early public reporting: a burst of hot-wallet transfers to new addresses, run with and without an independent pre-broadcast gate. It runs on test infrastructure, not Bitget systems.

Simulation based on public reporting. Not Bitget systems. Investigation ongoing.

Check your treasury's exposure

Sources

This analysis relies only on public reporting and is no longer updated. For current facts, use Bitget's official incident page. CryptOps is not affiliated with Bitget. Nothing here is investment advice.