The Bitget Hack: a CISO's Technical Analysis

On September 24, 2026, an attacker moved about $387.5 million out of Bitget’s hot and warm wallets. On the evidence so far, it never held a private key. It reached a production wallet server through two third-party security products, ran a purpose-built withdrawal tool that forged the risk-control fields, and let Bitget’s own signing service sign the transfers. The first trace of the intrusion dates to August 31, and about 61 percent of the value left after Bitget’s own alert had fired.

This briefing expands on our published summary. It draws on the Mandiant and SlowMist reports released on September 30, Bitget’s disclosures and the public on-chain record, as of October 2, 2026. Both forensic reports are preliminary, so we separate what the reports state, what we infer and what is still unknown.

The attacker was inside Bitget’s security tooling at least 24 days before the theft. The theft itself ran 2 hours 52 minutes, and the signing service stayed up for 2 hours 39 minutes after the first alert. Clock times are UTC, converted from the UTC+8 that SlowMist and Mandiant use. Entries with a date only keep the source’s date. 

SlowMist also records hidden-script activity on a third Product A node, dated September 25 in UTC+8.

On the evidence so far, the attacker did not need the keys, because it took over a host that tells the signer what to sign. Each stage below states what the forensic reports say, then what we infer from it.

Figure 1. Attack path: two security products, five pipeline stages.

The diagram is our reconstruction, because Bitget has not published its pipeline. Read it from the top left: the attacker’s lane joins the withdrawal path at the wallet job server, below risk control, so the controls above that line never saw its requests.

Both forensic teams trace the intrusion to two third-party security products running in Bitget’s production environment. SlowMist calls them Product A and Product B, and Mandiant calls them security appliances A and B. Neither names the vendor, and no CVE, advisory or patch is public as of October 2. We assume both reports use A and B for the same two products, and that SlowMist’s wallet application host is Mandiant’s wallet job server. Neither report says so.

On Product A, a zero-day in a service on one node let the attacker run a hidden script under the service process, read the environment variable holding the database password and connect to the database. The earliest instance in the available logs is August 31. The same pattern appears on two more nodes on September 23 and 25.

Bitget’s incident page says the attacker may have exploited the vulnerability to obtain high-level internal credentials. Its CEO stated the same without the hedge on September 28. SlowMist has not yet established how the attacker moved from Product A to Product B, so the link between that database and the identity used next is unconfirmed.

At 16:07 UTC on September 24 the attacker was on Product B’s management platform under an internal employee’s identity. It tried three times to inject system commands into task parameters to write malicious files. It then submitted code through the platform’s web execution endpoint in an attempt to change server configuration, write a communication relay file, and upload and assemble malicious program files in batches.

Mandiant reports a web shell and a command-and-control channel on appliance B. From that foothold the attacker moved to the production wallet job server and deployed malicious packages. Mandiant’s summary is that the appliances were used to distribute those packages and take control of the server.

Our reading: Product B is a management plane that can run tasks on the hosts it manages and push files to them. That reach turned a compromised security console into code execution on a wallet server. A relay file of that kind would be consistent with a tunneling web shell.

SlowMist recovered the tool from files the attacker had deleted. It was written for Bitget’s wallet system: it forged the risk-control parameters in its own code, built withdrawal requests and invoked the withdrawal process. Host logs show it starting at 17:49 UTC, 42 minutes before the first transfer.

Our reading, in three points:

1. A tool tailored to the withdrawal logic means the attacker studied the wallet system’s internals before the day of the theft. That fits a dwell time of weeks.
2. A forged risk-control parameter only works if the component that receives it trusts the caller. The risk decision appears to have traveled inside the request as a field, with nothing downstream verifying it independently.
3. On the EVM chains every traced transfer paid a single attacker address. Nothing in the signing path appears to have restricted where hot and warm wallet funds could go.

The tool tested first: 93 TRX and 0.84 ETH, eleven seconds apart. Bitget’s CEO said both sat below the risk-control thresholds and raised no alert. Twenty-eight minutes later it sent 34.75 million USDT, then hit five chains in 15 seconds.

At 19:03 a 0.65 ETH test left 0xffa8…cd54, a wallet Bitquery treats as warm. At 19:16 a 9-second burst took $203.1 million, $196.1 million of it from that wallet and a second warm wallet on the XRP Ledger. As we read it, the sequence repeats: test a tier, wait, drain it.

After 21:22 UTC the attacker also tried to modify withdrawal records directly in the wallet database and to invoke withdrawal tasks on the host. Two fabricated BTC withdrawal orders entered processing and returned errors, and the logs show the attacker reviewing logs, querying order status and retrying.

BTC is not among the assets Bitget lists as stolen. Neither report says why those orders failed. If a control rejected them, it is the one point where the pipeline refused, and the final reports should say which.
The attacker deleted its tooling and, according to Bitget’s CEO, the traces of the fraudulent commands. SlowMist recovered the tool from the deleted files.

Bitget’s own wallets signed every transfer, and the transfers do not look like customer payouts. That matches the forensic account: valid signatures on forged instructions.

Bitquery traced 23 transfers on nine chains, worth $386.80 million at the hour each one left. Bitget’s count is about $388 million across 11 chains and 12 wallet addresses, and it includes ALGO, TIA and ATOM transfers outside the public reconstruction. XRP was the largest asset: 102.98 million XRP, about $157.8 million, or 41 percent of the traced value.

Four details matter:

• Ordinary signatures in the ordinary queue. On Ethereum a theft sits between two customer payouts, with the next nonce and the same fee settings. The XRP transfers carry the same signing key and fee as a routine Bitget move made that morning.
• Gas limits that customer payouts never use. Customer ETH withdrawals from the two Ethereum hot wallets used a gas limit near 63,000. The seven theft transfers from those wallets used a fixed 100,000 or 200,000, and nothing else among the 35,678 transactions they sent in eight days did.
• A Zcash sweep. The Zcash hot wallet never used more than 54 inputs in thousands of earlier payments. The two theft transactions used 1,074 and 956, and took almost everything the wallet held.
• Warm wallets on the same path. Two wallets that Bitquery treats as warm sent about $214 million, 55 percent of the traced value. Five chains in nine seconds leaves no room for a human approver.

One of the two, 0xffa8…cd54, is marked cold in Bitquery’s own labels and by public trackers. Bitquery treats it as warm because it sends routine transfers most days and tops up the hot wallets. Bitget states that no cold wallet was affected.

The fixed gas limits show that the code that builds customer payouts did not build these transactions. Either the tool set the parameters itself or it used an internal transfer path. Bitquery notes that Bitget’s warm wallet uses fixed limits like these for its own internal transfers, which favors the second. The forensic reports do not say.

They also show what was detectable. The 0.84 ETH test at 18:31:11 already carried the anomalous gas limit. A monitor comparing each outbound transaction against the wallet’s own baseline had a signal 34 minutes before the reconciliation alert.

We map the incident onto the gates of a standard withdrawal pipeline. Bitget has not published its design, so the gate model is ours. The attacker entered below most of the gates, and nothing downstream caught the forgery.

Read together, the rows point to one design flaw. The signer appears to have trusted the wallet host, so whoever controlled that host inherited the authority of the whole pipeline.

Bitget is the latest in a run of exchange losses where the keys stayed safe and the instruction was forged. DMM Bitcoin and Bybit started in a vendor’s systems, and SlowMist described BigONE as a supply chain attack.

Detection took about six minutes from the first large transfer, seven by Bitget’s count. The signing stop took another 2 hours 39 minutes, and about $238 million of the $387 million traced left in that window.

Figure 2. Bitquery transfer record and Bitget response timeline, September 24, 2026, UTC.

Values use Bitquery’s pricing. Where it gives only a chain total, we apportioned it across that chain’s transfers by amount.

Bitget’s reconciliation system flagged the discrepancy at 19:05 UTC. By then about $149 million had left, nearly all of it in the previous six minutes. By the CEO’s account, the automatic response blocked user-initiated withdrawals across the platform. The attacker’s requests did not come through that path, and the transfers continued.

At 19:14 Bitget declared its highest-level emergency response. Two minutes later the second burst took $203.1 million in nine seconds. Transfers continued until 21:23, and the withdrawal and signing services went down at 21:44.

Bitget’s own timeline explains the delay. At 20:40 it had still not ruled out key compromise, and it began sweeping hot wallet balances to cold storage. Under that hypothesis a sweep is the logical move and stopping the signer is not.

The chain already contradicted the hypothesis. The thefts came out of Bitget’s own queue, in nonce order, between customer payouts. An attacker holding the keys signs on its own infrastructure and has no use for the victim’s queue.

So the first triage question in a wallet incident is whether the bad transactions are coming out of your own pipeline. Signer logs answer it in minutes. If they are, the response is to stop signing on every chain, and a stop at 19:05 would have kept about $238 million.

Almost none of the money is coming back, and the North Korea link is likely but unconfirmed.

The attacker dealt with the freezable assets first. All 34.75 million USDT was sold for ETH within 20 minutes of arriving, and the USDC and XAUt followed within about half an hour. Funds on Arbitrum, Avalanche, Optimism and Base were bridged to Ethereum. By September 26 the ETH sat in eight holding wallets, six of them with 10,000 ETH each.
 

THORChain declined Bitget’s request to block the attacker’s addresses, citing its permissionless design. Bitget’s CEO told CNBC, in an interview published on October 2, that she is not expecting to recover a lot. Bitget says its Protection Fund covers the loss and that customer balances are unaffected.

On attribution, the analytics firms agree and the forensic firms are silent. Elliptic rates a North Korea link as highly likely, citing on-chain ties to an earlier DPRK-attributed theft and to addresses used to launder the Bybit proceeds. TRM Labs calls it a likely North Korea attack, ties the laundering to a network TraderTraitor has used, and states that it has not definitively attributed the attack. ZachXBT reports that one of the launderers also moved funds from the Kelp DAO exploit of April 2026.

Bitget’s CEO has called North Korean involvement very likely, citing IP addresses that match VPN services used by a North Korean group. Bitget’s official position is that it will not speculate on attribution without verified findings, and Mandiant’s status report makes none. We found no government attribution as of October 2.

Our working assumption is TraderTraitor, the cluster the FBI named for DMM Bitcoin and Bybit. The tradecraft fits: weeks of quiet access, a tool written for one victim’s wallet system and the same laundering routes.

Both forensic reports are interim. Seven questions decide how far the lessons generalize.

1. Which products are A and B? No vendor, CVE, version or patch is public, so nobody can check exposure by product name.
2. How did the attacker get from Product A to Product B, and how did it obtain the employee identity? SlowMist is still investigating movement between the systems.
3. When did the intrusion start? Mandiant dates privileged access to the appliances to September 24. SlowMist’s logs show activity on August 31, and earlier logs may not exist.
4. Why did the two fabricated BTC orders fail, and did a control reject them?
5. What did the signing service verify about a request, if anything, beyond where it came from?
6. When did the first alert fire? Mandiant’s background section puts detection at 18:31 UTC. Bitget’s CEO says the tests raised no alert and detection came at 19:05.
7. What data did the attacker reach? It connected to a database on August 31 and reached the wallet database on September 24, and no report addresses customer or operational data.

There is nothing you can patch today. Bitget has notified the vendor and disabled the affected functionality, but no vendor, CVE or version is public. The work is to prove that a forged request from inside your wallet tier would not be signed. The eight controls below are ordered by impact, each with the evidence that shows it works. P is preventive, D is detective and R is responsive.

Controls 1 to 3 each close the path the tool used. Controls 4 and 5 together could have stopped the theft at the test transfers, provided the forged requests left no matching ledger order. The reports do not settle that. Controls 6 to 8 address the 24 days the attacker spent inside.

None of the first five holds if the same management console also reaches the risk engine and the approvers’ devices. Control 6 decides how much the others are worth.

Run a retrospective hunt as well. The earliest trace at Bitget predates the theft by 24 days, so look back at least 90 days for four things:

• security-product services spawning scripts or reading environment variables
• console logins under staff identities at unusual hours
• new files in the web roots of management platforms
• task parameters containing shell syntax

We are available to walk through these controls against your architecture.

Bitquery traced 23 transfers out of Bitget wallets on September 24, 2026, and checked each one against a public node for its chain. Values are priced at the hour of each transfer, and XRP at the price in the five minutes around each transfer.

The transfers in order. Warm marks the two wallets Bitquery treats as warm.

Bitquery identifies four first-hop attacker addresses. TRM Labs independently lists the EVM address.

• EVM chains: 0x770b10b273fC44Fe9197D6bF20F145c2e98463Ee
• XRP Ledger: rwNhefsz1UQEusxhCvHip3RANinWi4CTck
• Tron: TBWNguTTgezw9dVorX441C6nDrZpRxYwKD
• Zcash: t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG

The funds have since moved through hundreds of wallets. For screening, rely on your analytics provider’s tags, which follow the money several hops downstream.