Bitget Breach and Why Wallet Policy Controls Must Not Trust the Backend

TL;DR

• On September 24, 2026, Bitget reported about $351.6M in unauthorized transfers from its hot wallets. Later onchain estimates put the total at $387.5M after adding Zcash and Tron assets.

• No private keys were stolen. Bitget's CEO said the attacker compromised a backend system and spoofed transaction data that Bitget's own authorization process then approved.

• The signing process appears to have trusted data coming from the compromised backend without sufficient independent validation. Wallet policy controls exist so that even a trusted source can't send unlimited value to any address.

What happened in the Bitget hack?

Bitget detected unauthorized transfers at 18:31 UTC on September 24 and paused withdrawals, while deposits and trading kept running. Cold wallets were not affected, and Bitget said its User Protection Fund of over $464M covers the loss.

The day after, CEO Gracy Chen explained that "the attacker compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process." Industry reports indicate that initial access came through a vulnerability in third-party software. Bitget has said it will not speculate on the attack vector until its investigation is complete.

Funds moved across seven chains, including Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BNB Chain and Base, with about $158M in XRP. Bitget and blockchain analysts point to likely North Korean involvement.

How fast the funds left

The first signs showed up at 18:31 UTC, when small test transfers of 0.84 ETH and 93 TRX went to addresses Bitget had never used. Nothing stopped them, and 27 minutes later the first large transfer of $34.75M in USDT went through. The hot wallets then drained in two waves, first $87.6M across five networks in about 15 seconds and then $202.8M in about 9 seconds fifteen minutes later. On-chain data shows signing only stopped at 21:23 UTC, almost three hours after the first unauthorized transfer. The problem was not a lack of warning signs. The controls in place were not sufficient to automatically stop the drain.

Why did Bitget's wallets sign the attacker's transactions?

A hot wallet's signer has one job, which is to sign the withdrawals the exchange asks it to sign. At Bitget, destination and amount came from an internal service, and the signer had no independent way to check them. Once that service was compromised, every forged request looked legitimate.

This is the same pattern Dedge sees in smart contract audits. Contracts are usually built so that the admin is always trusted, and whoever holds the admin role holds unlimited power. Guardrails that limit that power are possible, but the industry rarely adds them. Exchange backends are treated the same way, and a trusted backend that is compromised becomes a trusted attacker.

How is the Bitget hack similar to Bybit?

In February 2025, Bybit lost over 400,000 ETH (about $1.5B) from its Ethereum cold multisig wallet. A forensic investigation found that attackers injected malicious JavaScript into the Safe{Wallet} web interface. Signers believed they were approving a routine cold-to-warm transfer. The transaction they actually signed replaced the wallet's implementation contract, which gave the attacker control. The FBI attributed the attack to the DPRK-linked group TraderTraitor, also known as Lazarus.

The two cases hit different wallet tiers through different routes, one a cold wallet through a compromised signing interface and the other hot wallets through a compromised backend. In both, the keys were safe and the signing process did exactly what it was told. The weakness was that nothing independent checked whether the request made sense.

Which wallet policy controls would have stopped it?

Published analysis indicates there was insufficient independent validation between the withdrawal request and the signing process. From Dedge's review of the published evidence, four controls address this attack pattern directly.

1. Transaction value and velocity limits. Hot wallets should not be able to send very large amounts in one transaction, or within a time window, without a second, independent approval.

2. Ledger verification before signing. Every withdrawal should be checked against the exchange's internal ledger, so the wallet only signs transfers that match a real customer request.

3. Destination allowlists. Large transfers should only go to addresses registered in advance, and that list must live somewhere the requesting service can't write to.

4. Automatic pausing. Alerts on abnormal outflows should pause the affected signers automatically, with the same monitoring across every chain.

It's worth being honest about what was foreseeable. Post-incident analysis found that the attacker's transactions used round gas limits such as 100,000 and 200,000, while Bitget's own system calculates precise values such as 63,000 and 136,620. That signal is clear in hindsight, but few teams would have thought to build a check for it in advance. Velocity limits and ledger verification are different. They are basic design decisions that any team can make during development, before an incident proves they were needed.

Allowlists are harder for hot wallets, because customers often withdraw to new personal addresses. Regulation helps here. Under the EU Transfer of Funds Regulation, exchanges must assess whether a self-hosted address belongs to the customer for transfers above EUR 1,000, which gives a basis for verified destination lists. The principle stays simple. A transfer of hundreds of millions should never reach an address nobody has registered, even when the request comes from inside.

Why existing wallet policy engines are not enough

Policy engines already exist in wallet infrastructure, with rules such as approved destinations and multi-person approval. They only protect assets when they are configured, when they cover every wallet tier and chain, and when the policy itself can't be changed by the system it is meant to restrict. None of the public reports on Bitget or Bybit show such limits applied to the drained wallets. What's missing is continuous visibility into whether policies exist, whether they remain correctly configured, and whether they are being bypassed.

How Dedge approaches wallet policy controls

Dedge is extending its Digital Asset Security Posture Management platform to wallet infrastructure. A wallet should not blindly trust the system requesting a transaction, and organizations need continuous visibility into the controls that limit what those wallets are allowed to sign.

Dedge connects to wallet infrastructure providers to discover wallets and their policies, evaluate whether critical controls are present and correctly configured, and identify security gaps. This extends the same security posture approach Dedge already applies across the digital asset lifecycle, from code and deployed contracts, and now to the infrastructure controlling digital assets.

Having a policy engine is not the same as having a secure policy posture.