Bitget CEO Gracy Chen used a Sept. 28 livestream titled Bitget Incident Review to give the exchange’s first full technical account of the Sept. 25 attack. She said the entry point was not Bitget’s own core code, but a vulnerability in a third-party security product. According to Chen, the attacker used that flaw to obtain internal network access credentials, then used those credentials to forge withdrawal instructions to the wallet system and slip past controls meant to block abnormal transfers.
Chen said private keys were not exposed at any point and cold wallets were not affected. She added that full technical details will be included in a formal security report. She also described the incident as Bitget’s first security event in the exchange’s eight-year history.
Attack path disclosed in detail
The livestream was the first time Bitget laid out the attack chain in full. The exchange said the attacker did not directly break into the wallet system. Instead, the route went through a third-party security product first, after which the attacker used stolen legitimate credentials to impersonate an authorized identity and issue commands. The report notes that BlockBeats compiled key points from Chen’s livestream.
Before this disclosure, BlockTempo had already reported on the hot wallet attack, the suspension of withdrawals, and the loss estimate being revised from $350 million to $388 million. The livestream added the missing explanation of how the breach unfolded.
Xie Jiayin says no malware was used
Xie Jiayin, Bitget’s head for the Chinese-speaking market, said the attacker did not use common viruses or malicious programs. Instead, he said, the operation relied on real identities and routine maintenance actions to disguise what was happening and to remove traces afterward. He called it “a relatively high-level targeted attack.”
Xie said Bitget has fully ruled out both private key leakage and insider involvement. In the company’s account, the attacker succeeded by exploiting a flaw in the third-party security product, stealing internal credentials, and then abusing those credentials to impersonate an authorized user.
Four remediation measures completed
Xie said Bitget has completed four corrective actions after the incident:
- Affected servers were isolated from the network, with evidence preserved for tracing.
- All internal login credentials were revoked and reissued, making the stolen credentials invalid.
- Highly sensitive permissions were withdrawn and restructured, and key operations now require multi-person approval.
- Bitget notified the third-party security vendor about the vulnerability and assisted with remediation, while suspending the affected function until the fix is complete.
He added that all future withdrawals must pass an independent verification process before release. Xie said the incident is fully under control, no new unauthorized transfers have appeared, the affected systems have been isolated, and all vulnerabilities have been fixed. Even so, each chain still has to pass multiple core checks before withdrawals can resume.
Protection fund and withdrawal progress
On the balance sheet side, Chen said Bitget has more than $1.4 billion in company-owned funds, including about $464 million in its user protection fund. She said the current loss falls within that coverage range and user funds remain safe. She also said Bitget’s proof of reserves remains at 127% and is publicly verifiable.
Chen also said the company will honor the commitment it made when the protection fund was established in 2022 and plans to replenish the fund to a $300 million baseline within one week. In her words, “The protection fund is not just a slogan, but an important mechanism that provides real protection for users during extreme security incidents.”
As for withdrawals, BlockTempo had previously reported that Bitget would restore them in four batches, with Bitcoin reopening first on Sept. 28. On-chain analyst Ai Yi (@ai_9684xtpa) said that after the BTC withdrawal portal reopened, a 5,500 BTC protection fund allocation began moving into hot wallets in batches to meet withdrawal demand. So far, 2,042.28 BTC, worth about $169 million, has been transferred, with 3,457.72 BTC still remaining on-chain.
Ai Yi said those transfers represent funds moved in advance and should not be treated as the same thing as actual withdrawal volume. The report says BlockBeats compiled the detailed on-chain tracking.
Asked why all assets were not reopened at the same time, Xie said the attack involved multiple chains rather than a single asset. Each step has to be checked and verified before users are exposed to any remaining risk, so recovery is being handled chain by chain and asset by asset. He said that schedule is unrelated to whether Bitget has enough funds.
Three observations raised in the source report
The source article also raised three observations about the case.
First, it pointed to a gap between two figures cited by Chen. On one hand, she said the $464 million protection fund is enough to fully cover the loss. On the other, she said Bitget plans to replenish the fund to a $300 million baseline within a week. The source article argued that placing those two figures side by side suggests the protection fund may already have been used, while the replenishment target is lower than the publicly stated fund size.
Second, the article highlighted the irony of a supply-chain style breach. The weak point was not Bitget’s own code, but a purchased third-party security product. The article said tools of that kind often hold elevated system privileges and are commonly trusted by default inside organizations, which can turn them into a fast route into internal systems if they are compromised.
Third, the article said there are limits to self-attestation. The conclusion that private keys were not leaked and that no insider was involved comes from Bitget’s own internal investigation. A formal security report has not yet been published, and no external third-party forensic result has been released. Until that happens, the article said, those conclusions remain the company’s unilateral account. It also noted that if the attacker really relied on legitimate credentials and routine operational behavior rather than malware, as Xie described, then proving the case through internal logs alone becomes harder.