Bitget reopened withdrawals in four batches after the Sept 25 attack

How the Bitget hot wallet attack happened

At about 02:31 on September 25, 2026 (UTC+8, which is 18:31 UTC on September 24), unauthorized transfers of assets began from part of Bitget's hot and warm wallet infrastructure on several chains. At 03:05 its reconciliation system found a clear discrepancy, and the risk control system automatically blocked withdrawal requests across the platform. Bitget puts the final verified amount affected at approximately $388 million and says user account balances remain unaffected. Withdrawals were paused after the incident and resumed in four batches from September 28; Bitget says the phased plan was completed on October 2.

This account follows the official explainer in Bitget Academy. The Chinese-language version is dated September 27, 2026. The times in the first hour, the recovery progress from September 28 onward, the investigation reports and the Protection Fund details come from the English version, Was Bitget Hacked? Bitget Security Incident: Timeline, Impact and Response, which is marked as updated October 3, 2026. Bitget describes the incident as contained, with asset tracing, recovery and follow-up security work continuing. If Bitget revises its figures later, its newer version takes precedence.

As Bitget describes it, the attacker compromised a critical back-end system in the exchange's wallet infrastructure, used it to forge transaction data and trigger the authorization flow, and moved assets out. It later added the point of entry: the latest investigation found that the attacker exploited a vulnerability in a third-party security product to obtain high-privilege internal credentials, then used those credentials to send forged withdrawal instructions to the wallet system, bypassing the risk controls in place. As for private keys, Bitget says that, based on the investigation, private-key compromise has been ruled out.

Bitget operates a three-tier wallet architecture of hot, warm and cold wallets. Its page limits the incident to a portion of the hot and warm wallet infrastructure and states that cold wallets across all chains were not affected. It dates the identification of the root cause to September 25 and reports that the underlying vulnerability has been remediated, with no further unauthorized transfers identified since containment.

Bitget hack timeline, September 25 to October 2, 2026

The initial assessment and the revision to about $387.5 million, both dated September 25, come from the Chinese version of the page; the English update of October 3 gives a single final verified figure of approximately $388 million. Bitget's English page gives the first three entries, and every entry from September 28 on, in UTC. The timeline above shows them in UTC+8, eight hours ahead, so 18:31, 19:05 and 19:14 UTC on September 24 appear as 02:31, 03:05 and 03:14 on September 25. The Chinese version records 02:31 as the moment the transfers were detected, while the English version splits the transfer and its discovery into two entries, and the timeline follows that split.

Why the affected amount rose from $351.6 million to about $388 million

The Chinese-language version of Bitget's page, dated September 27, carries two figures: an earliest estimate of about $351.6 million and a revised one of about $387.5 million, a difference of about $35.9 million (387.5 − 351.6). The reason it gives is a fuller count of the transfers during the incident, which added Zcash- and TRON-related transactions that the first estimate had left out.

The English update of October 3 states the final verified amount affected as approximately $388 million, involving 12 wallet addresses associated with hot or warm wallets. Bitget says that figure reflects the final verified accounting and classification of transactions tied to the original incident, and does not represent additional unauthorized transfers after containment or a separate security incident.

Bitget lists activity across 11 blockchains: Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand and Celestia. The affected assets identified to date are XRP, ETH, USDT, ZEC, ATOM, USDC, USD0, XAUt, BNB, AVAX, TRX, ALGO and TIA, 13 in all.

The asset list and the recovery table in the next section record different things. The list shows which assets were moved; the table puts withdrawal channels in order. BTC is absent from the identified list and still came back in the first batch.

When withdrawals reopened for each coin on Bitget

The 16:00 in the table is UTC+8, which is 08:00 UTC the same day; Bitget's own rollout table is in UTC and lists every batch at 08:00, starting on September 28. In any other time zone, convert from 08:00 UTC to your local time.

Bitget's page answers the question of whether withdrawals have fully resumed with a yes: BTC on September 28, ETH on September 29, USDT on September 30, and other supported tokens together with fiat and C2C services on October 2, the date it gives for completing the phased plan. It adds that the same approach applied across users, with no priority by account tier.

As of Bitget's October 3 update, the USDT row in its rollout table covers four networks, Ethereum, BSC, Solana and TRON, and the ETH row covers Ethereum, BSC, Arbitrum, Base and Optimism. A network outside those lists has no row of its own in the table. Whether a particular channel is open at a given moment is shown on the withdrawal page once you select the coin and its network. If the one you need shows as unavailable, Bitget's reminder is to refer only to its official website, app, Support Center and verified social channels; there is no need to turn to any other source.

Bitget states that trading and deposits continued to operate throughout the withdrawal-restoration process, and that fiat and C2C services were temporarily suspended after the incident until they resumed on October 2.

Does the Bitget Protection Fund cover the hack?

Bitget says user account balances remain unaffected, and that the withdrawal pause was a security measure unrelated to the sufficiency or availability of user assets. For the money moved in the attack, Bitget says its Protection Fund covers the financial impact of the incident. It describes the fund as an additional financial protection mechanism for eligible platform-wide security incidents, and this incident as falling within its coverage. On September 28 Bitget committed to replenishing the fund to at least $300 million within one week, and its timeline records the fund being replenished to more than $300 million at 17:00 (UTC+8) on September 30. The fund's wallet addresses, Bitget adds, can be viewed on-chain.

The Protection Fund is separate from Proof of Reserves. In Bitget's description, Proof of Reserves provides transparency into the assets the platform holds relative to covered user balances, while the Protection Fund is an additional layer of financial protection. At 23:59 (UTC+8) on September 29, Bitget published its 47th Proof of Reserves update, reporting an overall reserve ratio of 131% across 19 covered assets.

Two things in that report are worth checking for yourself: whether there is a way to confirm that your own balance was included, and how the reserves split between assets such as BTC, ETH, USDT and USDC on one hand and the platform's own token on the other. Both come under checking an exchange's proof of reserves.

Were coins in Bitget Wallet affected by the incident?

Bitget's answer is no. Bitget Wallet is a separate, non-custodial product running on infrastructure separate from the exchange wallet systems involved here, and users' assets remain on-chain under their own control.

The two names differ by a single word, which makes them easy to confuse in news coverage. The attack hit the hot and warm wallets behind Bitget exchange accounts. With Bitget Wallet the private keys are in the user's own hands, and its risks lie elsewhere, in things like seed phrase storage and mistaken approvals. An exchange account and a self-custody wallet go wrong in different ways.

Who hacked Bitget, and can the funds be recovered?

Nothing Bitget had published up to its October 3, 2026 update names who was behind the attack. Bitget says it engaged Mandiant, part of Google Cloud, and SlowMist to investigate the incident independently. The Chinese version of its page describes their brief as assessing the scope of the affected systems and assets, reviewing the attack path and method, verifying the containment and vulnerability fixes, assisting with fund tracing, and cooperating with the relevant authorities. Bitget's position is that information not yet formally verified should not be treated as a confirmed conclusion, public speculation about the attacker's identity included, and that attribution should be treated as confirmed only if verified investigative findings support it.

Reports from both firms became available on September 30. Bitget summarizes their findings as broadly aligning with the attack path identified earlier, with both investigations identifying the compromise of third-party security products as what ultimately enabled unauthorized access to its exchange wallet environment. Its stance on the attacker's identity was the same after the reports came out.

Bitget says law enforcement agencies and financial intelligence units have been notified, and that it is working with law enforcement, on-chain security specialists, exchanges, blockchain projects and other ecosystem participants to trace and recover the affected assets; some of those assets, it says, have already been frozen through coordination with industry partners. As of the October 3, 2026 update, the page gives no figures for how much has been frozen or recovered, and states that such amounts should be reported only once they have been verified.

Bitget has also opened a Recovery Bounty Program. Eligible voluntary actions that directly result in affected funds being frozen or recovered may qualify, subject to the program's terms and eligibility requirements, for a bounty equal to 5% of the amount frozen or recovered; assets frozen or recovered through law enforcement or other legal proceedings are not eligible. Bitget is also using Bybit's LazarusBounty as one of its recovery channels, and has published the attacker addresses it has identified along with related tracing information. The LazarusBounty name contains Lazarus, but on the same page Bitget leaves attribution to verified investigative findings, so the name should not be read as a verdict.