Bitget said a recent security incident that led to roughly $388 million in unauthorized transfers was caused by a zero-day flaw in a third-party security product, which attackers used to obtain high-privilege internal credentials, forge withdrawal instructions and bypass internal risk controls. The exchange said private keys were not exposed, cold wallets were not affected, and user balances will not suffer losses because the hit will be absorbed by its user protection fund.
The details were disclosed during a public livestream by Bitget CEO Gracy Chen and the company’s Greater China head Xie Jiayin. Bitget also said the cause and conclusions described in the session reflect the company’s current findings, and that the final account should still be based on an independent security report.
Bitget places the incident at 2:31 a.m. on Sept. 25, UTC+8
Chen said that at 2:31 a.m. on Sept. 25 in the UTC+8 time zone, some assets in Bitget’s hot wallet and warm wallet infrastructure were moved without authorization across multiple blockchains. The company’s investigation found that the attacker exploited a vulnerability in a third-party security product, obtained high-privilege internal credentials and injected forged withdrawal instructions into the wallet system, allowing the transfers to pass through as if they were legitimate.
She said private keys were not leaked and cold wallets were untouched. Bitget said the attack path has now been identified, the vulnerability has been fixed, the incident has been contained, and no new unauthorized transfers have been detected since. The value of the transferred assets was confirmed at about $388 million.
Bitget said Mandiant and SlowMist are assisting with the investigation and on-chain tracing, and that attacker addresses and related tracing data have already been made public. The company has also launched a bounty program for asset recovery and is working with security firms, law enforcement agencies, trading platforms, public blockchain projects and other industry participants to track and recover the funds.
For users, the company said the key point is that balances will remain unaffected. Bitget said it will not treat recovered assets as the main line of defense for user compensation, and that the entire loss will be covered by its user protection fund. After the fund is used, the company said it will replenish it with its own capital to at least $300 million in equivalent assets within one week.
Attack timeline: small test transfers first, then large multi-chain withdrawals
Chen walked through the sequence of events in detail.
At 2:31 a.m. UTC+8 on Sept. 25, the attacker first carried out two very small test transfers: 0.84 ETH from an Ethereum hot wallet and 93 TRX from a TRON hot wallet. Because the amounts were below the risk-control threshold at the time, no system alert was triggered, she said.
From 2:58 a.m. to 4:09 a.m., the attack entered what Bitget described as its most critical phase. The attacker initiated 17 large transfers across Ethereum, XRP, ZEC, BSC, Base, Arbitrum, Optimism and Avalanche, with a combined value of about $360 million.
Seven minutes after the first large transfer, at 3:05 a.m., the platform’s reconciliation system detected a significant discrepancy. Bitget said its risk system then automatically blocked user-initiated withdrawals across the platform. At 3:14 a.m., the exchange activated a P0 emergency response, its highest level. At 3:40 a.m., the technical team began loss-control measures.
At 4:40 a.m., because the company had not yet fully ruled out the possibility that private keys had been compromised, the wallet team began consolidating funds into cold wallets. From 4:55 a.m. to 5:23 a.m., the attacker launched a second round of seven transfers worth about $28 million, involving Avalanche, XRP, Ethereum, ZEC, ALGO, TIA and ATOM.
At 5:44 a.m., Bitget said its technical team halted wallet withdrawal services including signing machines and isolated inbound and outbound access related to withdrawals, while making a preliminary determination that private keys had not been leaked. At 4:43 p.m. that same day, the security team identified the root cause of the incident. At 9:42 p.m., the legal team reported the case to authorities in the relevant jurisdictions.
The following day, after completing the vulnerability fix, service isolation and security checks, Bitget said it finalized a plan to restore withdrawals in stages, starting with Bitcoin, then Ethereum, USDT, other tokens and finally fiat services.
How the forged withdrawal flow worked
Chen said the attack can be broken into three broad stages.
First, the attacker used a zero-day vulnerability in a third-party security product to steal Bitget’s internal network credentials and gain access to a critical internal management system. Because the credentials were real and valid, the system recognized the activity as a normal login.
Second, after obtaining high-privilege credentials, the attacker moved into wallet-related backend services and directly wrote forged withdrawal commands into the wallet system. Bitget said that caused the wallet to process those requests as normal withdrawals, letting the attacker bypass the risk checks that would normally occur before withdrawal records were generated, and move funds out of hot and warm wallets.
The third step was cleanup. Chen said the attacker deleted traces left by the forged withdrawal commands after each transfer, apparently to hide the operation and make root-cause analysis harder. Because direct evidence was limited, Bitget said it had to inspect a much broader range of systems, and post-fix validation had to cover more components, which lengthened the investigation and restoration process.
Chen added that the attacker did not use common viruses or malware. Instead, the operation relied on real credentials, was disguised as routine operational activity, and was followed by deliberate log cleanup. Bitget described it as a highly sophisticated targeted attack.
The exchange said it has ruled out private-key leakage and has also preliminarily ruled out the possibility of an insider job. Further investigation is being carried out with Mandiant and SlowMist. Before a formal report is released, Bitget said it does not want to speculate too much about the attacker’s identity and hopes to publish the investigation report within one week.
Bitget says the user protection fund will absorb the loss
Xie said the company has completed a fairly thorough tracing effort and believes the attacker used a flaw in a third-party security product to steal internal network permission credentials, forge withdrawal orders for the wallet system, deceive the wallet into executing them and bypass risk-control checks.
He said the attacker did not rely on common viruses or malicious programs, but instead used real identity credentials and routine operational behavior as cover while deleting traces afterward. Bitget has already ruled out the loss of private keys, he said. In the company’s account, the direct cause was the compromise of a critical backend system in the wallet infrastructure. After preliminary screening, Bitget also ruled out insider involvement.
On compensation, Xie said that when the protection fund was created in 2022, Bitget publicly committed to maintaining at least $300 million each month to provide rapid protection for user assets during black swan events. He said the exchange will top the fund back up to more than $300 million within this week.
Why withdrawals are being restored in phases
Xie said the incident involved many chains and tokens, and each chain must go through multiple core checks before withdrawals can be safely reopened. For that reason, Bitget is restoring withdrawal services in batches.
The order, he said, is Bitcoin first, then Ethereum and assets tied to Ethereum, BSC, Arbitrum, Base and Optimism, followed by USDT, and then the rest of the platform’s tokens and fiat withdrawals.
All users, including institutions, VIP clients and retail users, use the same withdrawal channel, Xie said, and no one has priority access. The original minimum withdrawal amount and the 24-hour maximum withdrawal limit remain unchanged. Users do not need to take any extra action, and the interface will display availability once withdrawals are restored.
He also addressed why the suspension lasted about three and a half days. The reason, he said, is that the compromised component was a critical backend system in the exchange’s infrastructure and affected the full withdrawal process. Bitget did not want to leave any hidden risk unaddressed before each part of the process had been inspected and verified. The event also spanned multiple mainnets and assets, meaning each chain required separate remediation and security validation.
Xie stressed that the withdrawal pause had nothing to do with whether funds were sufficient. At the time, Bitget’s protection fund stood at about $464 million and the reserve ratio was 127%, with both figures publicly available, he said.
Mitigation steps: system isolation, credential reset, tighter permissions
Xie outlined several remediation and risk-control measures that Bitget has already taken.
- First, the exchange isolated affected systems. All related servers were removed from the network to stop any further spread while preserving evidence for later tracing.
- Second, Bitget reset internal credentials and tightened high-sensitivity permissions. All internal login credentials were invalidated and reissued, making previously stolen credentials unusable. High-sensitivity permissions were withdrawn and split up again, and key operations now require approval from multiple people.
- Third, Bitget said it reported the vulnerability details to the relevant third-party security vendor to support analysis and remediation. Until the fix is complete, the company has stopped using the affected function.
- Fourth, the exchange strengthened withdrawal verification so that every withdrawal now requires independent verification.
According to Bitget, the incident is under control, no fresh unauthorized transfers have been found, the affected systems have been isolated and the vulnerability has been fixed. Still, each chain must complete several core security checks before withdrawals on that chain can resume.
Bitget says it will tighten vendor review and anomaly monitoring
On reducing risk from third-party security products, Xie said this was the first security incident in Bitget’s eight-year history, and that the scale of the event was a severe warning. He said the exchange will make changes in several areas.
Before adopting third-party security products, Bitget will apply stricter evaluation standards, he said. During deployment, it will strengthen security measures and isolation mechanisms to offset possible flaws in outside products. The company also plans to improve anomaly monitoring, maintain alert availability and stability, and increase the accuracy of alert judgments to reduce false positives and misses.
Asked whether the platform had previously conducted third-party audits and penetration testing, Xie said Bitget has done so consistently and has carried out security testing every year with firms including Hacken.
Bitget has also released a white-hat bounty program. If a participant helps proactively freeze attacker funds, the reward will be 5% of the relevant amount. If the participant directly helps recover funds, the reward will also be 5% of the relevant amount. Xie said the attacker’s addresses have already been made public and are being tracked in real time, and the related information and submission portal are also public.
Recovery expectations remain limited, Bitget says
On how much of the stolen funds might ultimately be recovered, Xie said the company is not optimistic.
Drawing on previous security incidents at other trading platforms, he said the share of assets actually frozen and recovered may remain very limited even after a year. Attackers in these cases are often highly professional and know how to move and obfuscate funds.
That, he said, is exactly why the user protection fund exists. The fund has been operating for four years, and Bitget’s commitment to keep it at no less than $300 million is intended to make sure user assets can be protected quickly under circumstances like these.
For now, Bitget is focused on raising the attacker’s cost of cashing out. Trading platforms that monitor related addresses, stablecoin issuers that can freeze addresses, and cross-chain bridges can all narrow the attacker’s exit routes, he said. But Bitget will not assume a particular recovery figure for the $388 million taken in this case, even as it continues tracing and recovery efforts. Xie also thanked trading platforms, public chains and project teams that have provided help.
Because the case involves a flaw in a third-party security product, Bitget is conducting a joint investigation with Mandiant and SlowMist and hopes to release a full security report within one week, he said.
Bitcoin withdrawal data after restoration
Chen said Bitcoin withdrawals have already resumed and explained why some users may still not have received funds.
She said a withdrawal has two parts. The first is the platform-side process: after a user submits a withdrawal on the app or website, it usually takes several minutes from order creation to batching and broadcasting on-chain. If a withdrawal order already has a TXID, that means the transaction has been broadcast to the blockchain and can be tracked through a block explorer. If there is no TXID yet, the order is still being processed by the platform.
The second part is processing by the Bitcoin network itself. Chen said Bitcoin’s target block time is about 10 minutes, but the real interval can range from a few minutes to dozens of minutes. If users send Bitcoin from Bitget to another trading platform, that destination platform typically waits for at least one block confirmation. So if a user already has a TXID but the funds have not arrived yet, the more likely reason is that the transaction is still awaiting confirmation on the Bitcoin network, not that it is stuck at Bitget.
Xie added that some users have already reported successful withdrawals, while more approved requests are still being packaged. He said Bitget increased staffing for withdrawal handling by about five times that day.
Chen said earlier in the session that withdrawal operations were running normally, with more than 6,000 withdrawal requests received, representing more than 2,700 BTC, and no obvious backlog. The first two to three thousand requests had already received blockchain confirmation. As restoration continued, Bitget also opened BTC withdrawals over BSC. Chen said Bitcoin mainnet is relatively slower and more expensive, while BSC is faster and cheaper, giving users another network choice.
She later updated the figures, saying the exchange had received more than 6,800 withdrawal orders corresponding to about 3,300 BTC. Some had already received at least one block confirmation, while the rest had been broadcast, assigned TXIDs and were waiting for on-chain confirmation.
In the final update during the livestream, Chen said that as of 4:50 p.m. UTC+8, Bitget had received 7,683 Bitcoin withdrawal orders totaling 3,609 BTC. Of those, 6,946 orders totaling 3,326 BTC had received at least one block confirmation, while 737 orders totaling 283 BTC had already been broadcast and were still waiting for on-chain confirmation.
She said the first batch of Bitcoin withdrawals moved relatively smoothly and showed no obvious backlog. In addition to Bitcoin mainnet, the platform had also received some BTC withdrawals through BSC, and those were also moving smoothly.
User compensation comes first, separate from recovery or liability
Chen said Bitget will not make asset recovery the main basis for user protection in this case.
In reality, she said, recovering stolen assets is difficult, especially when dealing with highly professional attackers familiar with money laundering and fund transfers. For that reason, user asset protection cannot depend on whether money can eventually be recovered from the attacker. That is why Bitget set up the protection fund in the first place, she said.
The asset recovery bounty is meant to make it harder for the attacker to process the funds. If trading platforms, stablecoin issuers and cross-chain bridges all refuse to handle related funds and freeze suspicious addresses, the attacker’s available exit routes become increasingly limited, Chen said.
Still, whatever amount is ultimately recovered, Bitget said it will cover user losses through the protection fund rather than wait for recovery results before acting. Chen said the company will use part of its existing protection fund, which stood at more than $400 million, and then replenish it to above $300 million within one week. The replenished assets will remain in public wallets so users can verify them on-chain in real time.
On whether Bitget will seek compensation from the third-party security vendor involved, Chen said the issue still needs to be discussed by the legal team. Although the third-party product had a related flaw, Bitget also bears responsibility as a trading platform, she said. Whether the company will pursue liability, and in what form, remains for the legal team to determine.
She said the logic is similar to asset recovery: neither the bounty program nor cooperation with the broader industry to make laundering harder will be treated as a precondition for compensation or user protection. Those protections continue to rest on Bitget’s user protection fund and the platform’s own security mechanisms.
Mandiant and SlowMist are now conducting independent forensics, including assessing the affected systems and asset scope, attack path and methods, validating Bitget’s loss-control and remediation steps, and supporting fund tracing. Bitget said the independent investigation report is expected within one week.
Chen closed by saying this was the first security incident in Bitget’s eight-year history. Based on the current investigation, she said, the main cause was a vulnerability in a third-party security product, and more details will be disclosed in the independent security report.