When the approved withdrawal is the theft

A withdrawal can be approved inside the company and still be the theft.

The request sits inside the normal system. The risk check says it passed. The record, if one is written at all, looks like a withdrawal the company meant to send. The keys sign it, because nothing in front of them is allowed to question an internal approval.

The keys stayed in place. What the signer trusted was the approval.

What was reported

On September 24, 2026, Bitget reported unauthorized transfers from a portion of its hot and warm wallets, the wallets kept online so withdrawals can be paid quickly. The exchange later put the verified total at about $388 million, across 12 of those wallets. It said the offline cold wallets were not affected and that private keys were not compromised. Customer withdrawals were paused and later restored in stages, with the last of them back on October 2. Bitget has not confirmed who did it, and this article does not either.

Bitget’s account, and independent reports from Mandiant and SlowMist released on September 30, describe the same path. Attackers used a flaw in third-party security appliances to reach the production system that prepares withdrawals. Investigators recovered a program, built for that system, that filled in the fields marking a withdrawal as approved, constructed the withdrawal requests, and called the existing withdrawal process. The exchange’s own signers then signed.

Small payments went out first, then larger ones. Pausing ordinary customer withdrawals did not stop transfers already moving through the withdrawal process the signers follow.

Where the approval failed

Two facts explain the loss.

One system chose the destination and marked the payment approved. The fields that mean “this is allowed” were written by the same machine that chose the recipient. No second role signed off on who was paid, which asset moved, and how much.

The keys trusted that internal record. Once the request looked valid, the signers did what they are built to do. They had no separate record, outside that server’s reach, of the payment itself. Investigators later recovered the program from files the attacker had deleted.

If the system that marks a withdrawal approved can also choose the destination, the approval is a step in the theft.

What the signer has to refuse

A signer turns a request like this away when the machine that was taken over cannot write the approval the signer trusts.

Preparing a payment and authorizing it are different roles. The withdrawal service can submit the request. It cannot sign the authorization.

The authorization names the exact payment. Who is paid, which asset, and how much. Change any of those after the signature and the authorization no longer matches.

A payment without that second signature waits. The account records the exact payment and does not settle until the waiting period ends. Teams that need to pay immediately use another path, which skips the wait on purpose. That path holds only when the authorizing key is kept where the withdrawal service cannot reach it. If both keys sit on the compromised server, the separation is gone.

Widening who may request a payment, or what the account is allowed to do, is its own authorized action. The breached server cannot make that change by itself.

What this still leaves open

The separations above do not stop the break-in. The appliances, the stolen access, and the move onto the withdrawal server all happen before anything reaches the chain. What changes is which payments a fully owned withdrawal server can still make the account settle.

Permission to pay a given asset does not limit the amount or the recipient. Any amount, to any address, can still fit that permission. A cap, or a list of allowed recipients, is a further control. This article does not claim either one.

The same separation has to be in place on every network you pay from. Several networks in the reported loss sit outside an account of this kind. Care on one network does not govern the others.

This case stops there. The general argument, why an approval process can record consent and still leave the payment unbound, is Why Approvals Alone Don't Prevent Costly On-Chain Mistakes. If signing itself is still being treated as the whole control, the prior step is Why Multisig Doesn't Solve Team Governance.

For the enforcement layer Particle CS maintains, start at the Bloxchain Protocol on GitHub (opens in a new tab) and docs.bloxchain.app (opens in a new tab). Platform and Protocol share the same on-chain policy. Administration and treasury-oriented product surfaces are alpha. This article is a control lesson, not a claim that a given deployment would have changed this incident. The protocol audit covers the core framework (Nethermind NM_0828), not a custom exchange integration.