Security
Bitget Says the Thief Came In Through a Security Product It Won't Name
The exchange's new timeline moves the moment of detection from 18:31 UTC to 19:05 and puts the blame on a flaw in a vendor's product. On Ethereum, about 71 percent of the ETH sent straight to the attacker left after the alarm, and the last of it arrived 74 minutes after the final transfer the chief executive described.
Bitget's first notice about the theft opened with a time. "At 18:31 UTC on September 24, 2026, Bitget's security systems detected unauthorized transfers from some of our hot wallets."
The exchange's incident page, updated September 29, uses the same minute for something else. 18:31 is now when "the first unauthorized transfers occur." Detection comes 34 minutes later: at 19:05, "Bitget's reconciliation system detects a significant discrepancy, and the risk-control system automatically blocks withdrawal requests across the platform." In other words, the first alarm was an accounting mismatch, raised after money had already left.
The same page gives Bitget's first account of how the attacker got in. "Based on the investigation to date, the attacker may have exploited a vulnerability in a third-party security product to potentially obtain high-level internal credentials," it says. The attacker "then appears to have used these credentials to send fraudulent withdrawal commands to the wallet system." That is three hedges in two sentences, and no product name. The estimate is now approximately $388 million, taken from 12 wallet addresses on 11 blockchains.
A product with other customers
Chief executive Gracy Chen went further on September 28. According to The Block, she said the attacker reached an internal management system through a zero-day in the product, then deleted the traces the fraudulent commands left behind, which she called "the trickiest part." She did not name the product either, The Hacker News noted.
Bitget's page says it "has notified the relevant third-party vendor and disabled the affected functionality pending completion of a fix." It also says "the underlying vulnerability has been remediated." Both can be true if remediation, at Bitget, means switching the feature off. But the first sentence says the vendor's fix was not finished when the page was last updated. The Hacker News put the open question plainly: "Bitget has not said whether the vendor has released a fix."
Security products are rarely sold to one customer. None of the reports the Desk read identifies this one, and the Desk is not going to guess.
What the chain shows
Chen's account, as The Block reported it, has two test transfers at 18:31, "0.184 ETH from an Ethereum hot wallet and 193 TRX from a Tron hot wallet," both under the risk-control threshold. Then 17 large transactions between 18:58 and 20:09, worth about $361 million.
Bitget published the attacker's receiving addresses in its September 25 update, so part of this can be checked. The Desk read every direct transfer into the Ethereum address, 0x770b…63Ee, on Blockscout. The first arrived at 18:31:11 UTC from a wallet Blockscout labels "Bitget: Hot Wallet." It carried 0.84 ETH, not 0.184. The Desk cannot say whether the smaller figure is Chen's or a slip in the reporting of it.
The large transfers begin at 18:58:59 with 34.75 million USDT, which matches Chen's start time. A second test, 0.65 ETH, comes from a different Bitget-labeled wallet at 19:03:23. Thirteen minutes later that wallet sent 13,965.93 ETH, the largest single ETH transfer into that address and one made 11 minutes after Bitget says its systems noticed.
September 24: Bitget's timeline beside Ethereum mainnet (UTC)
| Time | Bitget's account | Into 0x770b…63Ee |
|---|---|---|
| 18:31 | First unauthorized transfers; no alert | 0.84 ETH |
| 18:58–19:03 | Large transfers begin | 34.75M USDT, 12.85M USDC, 3,000 XAUt, 7,130.86 ETH, 0.65 ETH |
| 19:05 | Reconciliation flags a discrepancy; withdrawal requests blocked | |
| 19:16 | 13,965.93 ETH | |
| 19:40 | Containment measures begin | |
| 20:09 | Last of 17 large transactions | 1,879.2 ETH and 1,395.9 ETH |
| 20:40 | Wallet team starts moving funds to cold wallets | |
| 21:23 | 223.2 ETH | |
| 21:44 | Signing services shut down |
Two more transfers land twelve seconds apart at 20:09, which matches Chen's end time. Then there is one she did not describe. At 21:23:11, the wallet that sent the 18:31 test sent 223.2 ETH to the same attacker address. That is 74 minutes after 20:09 and 21 minutes before Bitget's timeline says signing services were shut down.
Added up, 24,596.58 ETH went directly to that address on Ethereum mainnet, and 17,464.23 of it, about 71 percent, left after 19:05. Some caution is due. Wallet labels on a block explorer are inferences. This is one chain of eleven. The 223.2 ETH transfer may fall outside what Chen counted as "large," and Bitget has not addressed it. What the record does show is the transfer, its sender, its destination and its time.
Blocked for whom
The timeline explains how withdrawals could be blocked at 19:05 and continue until at least 20:09. The Block's report says the risk system stopped "user-initiated withdrawals." By Bitget's own description, the attacker was not submitting withdrawal requests. The commands went straight to the wallet system, which kept signing.
Bitget's page dates the shutdown of "wallet withdrawal services, including signing services" to 21:44, three hours and thirteen minutes after the first transfer. One entry in between may explain part of the delay: at 20:40, "as private-key compromise has not yet been ruled out, the wallet team begins transferring funds to cold wallets." Moving funds to safety needs a working signer. That reading is the Desk's. Bitget has not said why the signers stayed on.
Attribution, half withdrawn
On September 25 Chen pointed toward North Korea. TRM Labs wrote the same day that on-chain overlaps "point to TraderTraitor," while adding that it "has not definitively attributed the attack."
Bitget now speaks with two voices. "What was shared previously was based on preliminary indicators identified during the investigation," Chen told Cointelegraph. "Those indicators are still being assessed." The Block quotes her from the same day: "It's still the same group of people that we suspect." The incident page says Bitget "will not speculate on attribution while the independent forensic investigation remains ongoing."
What customers have now
Bitcoin withdrawals reopened at 08:00 UTC on September 28. By 09:00 UTC Bitget had processed 9,585 of them, totaling about 4,098 BTC, Bitcoin.com News reported. ETH followed on September 29. USDT is scheduled for September 30 and everything else for October 2. The page says employees and VIP clients are on the same schedule as everyone else.
The list of affected assets has grown from ten to thirteen since September 25, adding ATOM, ALGO and TIA. Chen said the protection fund will absorb the loss and be topped up to at least $300 million within a week from corporate reserves, per The Block. Bitget's first notice put the fund at more than $464 million. Mandiant and SlowMist are still investigating, and the formal report is expected this week.
The Take
The detail that ought to worry other exchanges is the one Bitget has withheld. If a security product was the entrance, every other customer of that product has an interest in knowing which one, and "pending completion of a fix" says the vendor was not finished on September 29. There may be good reasons to hold a name until a patch ships. There is no good reason to hold it afterward. The timeline deserves credit for existing, because most exchanges never publish one, and this one corrects the company's own first sentence. It also shows where the control was missing. A block on customer withdrawals does nothing when the thief is not a customer. The signer kept honoring commands for at least an hour after the books stopped balancing, and on Ethereum most of the ETH left in that hour. The formal report should give the time of the last unauthorized transfer on every chain. If it says 20:09, it should explain 21:23.