BLOCKCHAIN AI.NEWS

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.

Editorial illustration: a small chrome and frosted-glass guard booth stands with its side panel hanging open and gold light spilling out, while a row of frosted glass cubes rides a blue-lit rail out of a steel vault door
✓ Attack path and timeline from Bitget's incident page (updated Sep 29) and its Sep 24 notice · Earliest report this desk found: crypto.news (Sep 28) · Test transfers and the 18:58–20:09 window first reported by The Block · Also Cointelegraph, The Hacker News, TRM Labs · Transfers into the attacker's Ethereum address read on Blockscout by this desk

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)

TimeBitget's accountInto 0x770b…63Ee
18:31First unauthorized transfers; no alert0.84 ETH
18:58–19:03Large transfers begin34.75M USDT, 12.85M USDC, 3,000 XAUt, 7,130.86 ETH, 0.65 ETH
19:05Reconciliation flags a discrepancy; withdrawal requests blocked
19:1613,965.93 ETH
19:40Containment measures begin
20:09Last of 17 large transactions1,879.2 ETH and 1,395.9 ETH
20:40Wallet team starts moving funds to cold wallets
21:23223.2 ETH
21:44Signing services shut down
Sources: Bitget's incident page; the 18:58 start and 20:09 end are Gracy Chen's, via The Block. Right-hand column: direct ETH and token transfers on Ethereum mainnet only, read from Blockscout. Other chains are not shown.

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.

More on the subject