Bitget $387.5M Hack: How Spoofed Requests Got Signed

TL;DR

On September 24, 2026, attackers moved $387.5 million out of Bitget's hot and warm wallets across Ethereum, the XRP Ledger, Tron, Zcash and five other EVM networks. They never stole a private key. According to Bitget's CEO Gracy Chen, the attacker exploited a vulnerability in a third-party security product to steal internal network credentials, forged withdrawal instructions to the wallet system, and bypassed risk control checks. The wallet signer did the rest. Bitget's systems flagged the first unauthorized transfer at 18:31 UTC, yet attacker transfers kept being signed until 21:23:11, and $290.4 million of the loss left in two bursts after that first alert. Elliptic and TRM Labs assess the attack as likely North Korean. Bitget's User Protection Fund is covering customer losses and withdrawals are reopening in stages from September 28. The lesson for every custodian: a signer approves whatever it is shown, so "the keys are safe" and "the funds are safe" are two different claims.

What Happened at Bitget on September 24?

Bitget's security systems detected unauthorized transfers from some of its hot wallets at 18:31 UTC on September 24, 2026, as reported by Decrypt. Outside eyes got there early. Arkham Intelligence analyst Emmett Gallic flagged the unusual wallet movements before Bitget's own announcement, according to CoinDesk, which also carried Chen's first description of the blast radius: Bitget runs a three-tier wallet architecture, and the breach reached "only a portion of the hot wallet and warm wallet layers." Cold storage was untouched.

The first official number was $351.6 million. A day later Bitget's incident update revised it to $387.5 million, explaining that the increase reflects assets on Zcash and Tron that had not been counted. The affected tokens were XRP, ETH, USDT, ZEC, USDC, BNB, AVAX and TRX.

Withdrawals were paused while deposits and trading stayed up. CoinDesk reports Bitget's User Protection Fund holds more than $464 million. Chen said the loss will be fully covered by that fund and that Bitget will replenish the fund to at least $300 million within one week of drawing on it. The Block published the reopening schedule: BTC on September 28, ETH on September 29, USDT on September 30, and everything else, including fiat and P2P, on October 2.

How Did Attackers Drain a Wallet Without Its Keys?

A hot-wallet signer holds (or can reach) a private key and signs transfers on request. An upstream service tells it the destination, the amount and the chain, and the signer turns that request into a valid signature. If the request is a lie, the signature is still valid.

That is the whole attack. Hypernative's reconstruction puts it in one line: the signer "trusted an internal service to tell it the destination and amount."

Bitget's account has two halves that look contradictory until you read them as layers. Chen told Decrypt the attackers "did not forge user withdrawal requests, nor did they obtain our private keys." In a later statement reported by PANews, she said they "forged withdrawal instructions to the wallet system." Both can be true. No customer withdrawal was faked. The forgery sat one layer down, in the internal instruction that tells the wallet system what to sign, which is the layer the signer trusted without checking.

The way in was a security product. Bitget described the incident as a special attack targeting the supply chain of third-party security software, in which the attacker exploited a vulnerability in that product to obtain internal network credentials. The Block reports those were "high-level internal credentials." Bitget has not named the vendor or the product, and says it is working with Mandiant and SlowMist on an independent review and will "comprehensively upgrade its monitoring and management standards for third-party components." (The door into the wallet system was a tool bought to guard it.)

Three things are not public yet. Bitget says it has identified "details of how the attacker bypassed existing security controls" but has not published them, so whether a second control existed and also failed is unknown. It has not said how long the attacker held the stolen credentials before the first forged instruction. And it has not said why the 18:31 detection did not halt the signer, or whether a pause needed a human decision. That last one is the question we most want answered, because it decided $290.4 million. The full report Bitget promised should settle all three.

The weakness class is old. CWE-345, insufficient verification of data authenticity, describes a product that "does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data." Read "product" as "signer" and "data" as "withdrawal instruction".

The Attack, Step by Step

Times are UTC on September 24, 2026, from Hypernative's on-chain timeline unless noted.

Step	Time	What happened	Why it worked
1	Before 18:31	Attacker exploits a vulnerability in a third-party security product and takes internal network credentials	The product sat inside the network with enough reach to expose high-level credentials
2	Before 18:31	Attacker uses the credentials to push forged withdrawal instructions to the wallet system	The instruction channel was trusted; risk control checks were bypassed
3	18:31	First test transfers: 0.84 ETH and 93 TRX to fresh addresses	Small sends confirm the forged path produces real signatures
4	18:31	Bitget's security systems detect unauthorized transfers	Detection fired; signing did not stop
5	18:58	First large transfer: 34.75M USDT	A single eight-figure send leaves the hot wallet
6	19:01	Hot wallets send $87.6M in seven transfers across five networks in 15 seconds	Signer processes forged requests at machine speed
7	19:16	Warm wallets send $202.8M across five networks in 9 seconds	The warm tier trusted the same instruction path
8	21:23:11	Final attacker transfer is signed	2 hours 52 minutes after the first detection
9	Within minutes	Stablecoins swapped to ETH, ETH split into 10,000 ETH lots, XRP split across new accounts, BNB routed to Bitcoin	Freezable assets converted before any freeze landed

On-chain, the biggest native ETH send in Hypernative's list, 7,130.86 ETH from the wallet Etherscan labels Bitget 6 to the address labeled Bitget Exploiter 1, landed at 19:01:35 UTC in block 26049267.

rendering diagram…

The Gas-Limit Tell: What Gave the Attacker Away?

The forged requests were almost perfect. One field was wrong.

Bitget's pipeline calculates a gas limit for each withdrawal, so its values look like 63,000 or 136,620. Per Hypernative, "the attacker's requests arrived with fixed round numbers instead: 100,000, 200,000 or 50,000,000." On Bitget 6, "the only native ETH sends with a 200,000 gas limit were the attacker's." The 7,130.86 ETH transfer above shows exactly that: a 200,000 limit, 21,000 used.

A human reviewer never looks at that field and a rule never misses it. It does not generalize cleanly, though. Hypernative notes that Bitget 35, a low-volume warm wallet, uses round gas limits in its routine traffic, and that XRPL and Tron transactions have no comparable field at all. The three non-EVM networks account for about half of the total. A monitoring program built around one EVM quirk would have seen half the theft.

Hypernative sells monitoring, so treat its recommendations as a vendor's. Its timestamps are on-chain and the ones we checked hold up.

How Much Was Really Taken?

We trust $387.5 million, with one soft leg.

The number moved twice in public: independent researchers first tracked about $183 million, Bitget's first statement said $351.6 million, and its September 25 update said $387.5 million. Hypernative's per-network breakdown lines up with that revision: $157.7M on the XRP Ledger, $126.5M on Ethereum, $7M on Tron, and about $29.4M on Zcash, with the remainder spread across Arbitrum, Base, Optimism, Avalanche and BSC. The Tron and Zcash legs together add roughly $36M, which is the gap between the two official figures within rounding.

The soft leg is Zcash. Hypernative draws it dashed and labels it "probable," and it is the one component we cannot check on a public explorer the way we checked the Ethereum send. The XRP figure is firmer: Decrypt reports about 103 million XRP taken, and Hypernative found 102.28 million XRP sitting across five XRPL accounts at its snapshot.

Who Did It, and Where Did the Money Go?

Attribution is an assessment, not a finding. Chen told Decrypt that Bitget had identified IP addresses matching the VPN choices of North Korean groups, and that the patterns "look very much like what the North Korean team did before." Elliptic assesses the attack as highly likely DPRK-linked, citing connections between XRP from Bitget and ETH from a previous DPRK-attributed exploit, plus links to addresses used to launder the 2025 Bybit theft. By Elliptic's count, Bitget pushes suspected North Korean crypto theft past $1 billion for 2026, a year that already included the Drift Protocol exploit (Elliptic's $286 million, the top of the $270 to $286 million range we reported in April). TRM Labs reports on-chain overlaps with earlier North Korean thefts including Bybit and the AFX bridge, and the same laundering syndicate used by the TraderTraitor group.

Stablecoins first. Hypernative traced about $88.3M in USDT, USDC, USDT0 and XAUt to a swap hub, "an EIP-7702 account delegated to MetaMask's smart-account contract," where the USDT was being sold for ETH through UniswapX fillers and Uniswap pools 1 minute 48 seconds after it arrived. None of that freezable $88.3M was frozen on its original legs.
Pull everything home. Proceeds on Base, Optimism, Arbitrum and BSC came back to Ethereum through intent-based bridges, and Avalanche USDC through Circle CCTP. Elliptic reads the Arbitrum move as a lesson learned from the KelpDAO incident.
Then park it. TRM followed the ETH through 0x770b10b273fC44Fe9197D6bF20F145c2e98463Ee into eight wallets holding about 10,000 ETH each, and the XRP into accounts of roughly 20 million XRP apiece. About 5,032 BNB went to Bitcoin through THORChain. As of Hypernative's September 25 snapshot, roughly $341M had not yet been laundered.

That split is the attacker's economics in plain view. Anything an issuer can freeze gets converted in under two minutes. Anything nobody can freeze gets split into round lots and parked.

Bitget is paying a 5% bounty on anything frozen or recovered, and The Block reports some assets are already frozen.

Why Does "The Private Keys Were Not Leaked" Not Reassure?

Because for a hot wallet, the control that matters is the instruction channel.

Custody assurance is built around key protection: hardware modules, key sharding, signing ceremonies, cold-storage audits. All of that answers "who can hold the key?" Bitget's answer held. Nobody took a key.

The question that failed was "who can tell the key what to sign?" A custody review that certifies key handling says nothing about the service that feeds the signer.

This has happened before at larger scale. In February 2025, Elliptic documented how Bybit lost about $1.46 billion after malware was used to trick the exchange into approving transactions that sent the funds to the thief. Different wallet stack, same lesson: the signer approved what it was shown. Elliptic's on-chain links between the two thefts suggest it may be the same crew.

We made the smaller version of this argument in July about Triple-A's $11.8M hot-wallet drain, where deposits kept being swept for 31 hours after the theft began. The same year, Drift's Security Council signers approved misleading transactions an attacker had prepared for them.

What Should Exchanges and Custodians Do Now?

Bind every signature to a record the requester cannot write. A hot-wallet transfer should sign only if it matches a customer withdrawal record, or a treasury allowlist entry, held in a store the requesting service has no write access to. Hypernative's first recommendation says the same. This is the control that turns a forged instruction into a rejected one.
Reject requests your own pipeline would never produce. If your system computes gas limits, fee settings or memo formats a particular way, a request with different values did not come from your system. The next attacker will get the gas limit right, so check every field you generate.
Cap velocity per wallet tier and require a second approval above it. Seven transfers worth $87.6M in 15 seconds, and $202.8M out of warm wallets in 9 seconds, are not customer behavior. A second, independent approver above a per-tier limit makes the attacker beat two systems instead of one.
Make the alert stop the signer. Bitget detected the theft at 18:31 and signing continued until 21:23. An alert that only pages a human ends up as a timestamp in the postmortem. Have it pause the affected signer.
Monitor XRPL, Tron and every non-EVM wallet as closely as the EVM ones. About half of this loss moved on networks with no gas-limit field. Rules keyed to EVM quirks leave those wallets unwatched.
Treat security vendors as part of the attack surface. The entry point was a third-party security product. Scope its network reach and credentials as tightly as any other vendor's, and assume its compromise is one of your incident scenarios. Our key-compromise runbook covers the first hour.

Where Does Monitoring Fit in an Attack Like This?

Nothing on-chain precedes a backend compromise, so the first observable moment is the first signed transfer, and that is where every signal below sits. Five of them were visible in the first 45 minutes: test sends of 0.84 ETH and 93 TRX from exchange wallets to fresh addresses at 18:31; a single 34.75M USDT transfer out of a hot wallet at 18:58; seven hot-wallet transfers worth $87.6M across five networks inside 15 seconds at 19:01; a 200,000 gas limit that, on Bitget 6, only the attacker's native ETH sends carried; and $202.8M leaving warm wallets in 9 seconds at 19:16. Bitget did detect the first of these. It did not stop the signer, and $290.4M left after the alert. Tripwire is built to alert on this class of event across the wallets you name: outflow velocity per wallet, a first-ever destination receiving eight figures, a transaction field your pipeline never produces. Wire that alert to your signer's pause and the 18:31 detection becomes a stopped queue.

For exchanges building or reviewing the signing path itself, the instruction channel between the withdrawal service and the signer is where a full security audit should spend its time, because that is the path this attacker walked.

Frequently Asked Questions

Were Bitget's private keys stolen?

No. Bitget says private keys were not leaked and cold wallets were unaffected. The attacker used stolen internal credentials to send forged withdrawal instructions to the wallet system, and the signer produced valid signatures for them.

How much did Bitget lose in the hack?

$387.5 million, per Bitget's September 25 update, revised up from an initial $351.6 million after Zcash and Tron assets were counted. The largest shares were about $157.7M on the XRP Ledger and $126.5M on Ethereum.

Are Bitget users' funds safe?

Yes. Bitget says its User Protection Fund, which held more than $464 million, covers the full loss. Withdrawals reopen in stages from September 28.

Was North Korea behind the Bitget hack?

Not confirmed. Bitget's CEO pointed to IP addresses matching North Korean VPN choices, and Elliptic and TRM Labs assess the attack as likely DPRK-linked based on on-chain overlaps with the Bybit theft and other prior incidents. Decrypt notes no official confirmation had been provided.

Bitget's $387.5M Hack: Its Own Signer Approved the Drain, and the Keys Were Never Stolen