Bitget's breach: how forged withdrawals reached the wallets

1 The compromised system belonged to the exchange

This incident affected part of Bitget Exchange's hot and warm wallet infrastructure, used for day-to-day asset movements and withdrawals. Bitget says its cold wallets, which hold most platform assets, were unaffected. The similarly named Bitget Wallet is a separate, non-custodial product with different infrastructure; the company says it was not involved.

In its explanation updated on September 30, Bitget says it isolated affected systems, revoked and reissued internal credentials, restructured sensitive access and disabled affected functionality while awaiting completion of a vendor fix. The forensic reports are interim findings and do not give a complete verification of the repaired environment. Appliance vendors, vulnerability identifiers, internal interfaces and risk-field names also remain unpublished.

Customers need to know whether they can withdraw their money. Bitget promises that account balances will bear no loss and that its Protection Fund will cover the financial impact. Withdrawals are reopening by asset and network. A balance can remain visible while a particular withdrawal route is still closed; the final section lists the reopening notices available at the research cutoff.

2 From a security appliance to a wallet server

The intrusion left traces well before funds began moving. On pages 2–3 of its report, SlowMist dates the earliest activity in the available logs to August 31: an attacker exploited a zero-day in a node service belonging to security product A, ran a hidden script inside the service process, read a database password from environment variables and connected to the database. Similar script activity appeared on two other nodes on September 23 and 25. Infrastructure secrets were exposed before the theft; this starting point does not establish continuous control of the whole wallet environment from late August.

The database password was in environment variables so that the service process could connect. A hidden script running inside that process could read it and try to use the same permissions. The report does not disclose the database account's full privileges, leaving the extent of reachable data and systems unknown.

Security product B appears next. SlowMist records access to B's management platform under an internal employee identity early on September 25, followed by attempts to inject operating-system commands into task parameters and write malicious files. Code submitted later attempted to change configuration, establish a communication relay, and upload and assemble program chunks. The report does not publish the complete credential path from A to B, leaving that transition unresolved.

Mandiant's September 28 status report supplies an important part of what happened after B was compromised. An attacker deployed a web shell—a backdoor that accepts commands through web requests—and established a remote-control connection. Persistent access on B then supported lateral movement to the production wallet job server, where malicious packages were deployed. A job server runs wallet-related tasks. Reaching it brought the attacker to software that could advance the withdrawal process.

The backdoor on B had already provided access to the wallet server. Patching the appliance alone would leave that later access unaddressed. Recovery also requires revoking issued credentials and established connections, then checking which machines the appliance may reach and whether its credentials can still be used for wallet tasks.

3 A backend machine began requesting the attacker's withdrawals

The withdrawal tool SlowMist recovered from deleted files was tailored to the wallet's business logic. It forged risk-control parameters, constructed requests and called the existing withdrawal process. Host logs place the malicious program's execution and theft activity at 01:49 on September 25, Beijing time. The risk fields remain unnamed, so it is unclear whether the tool changed an approval status, a verification result or another business value.

What would make such a request properly approved? In a typical withdrawal system, approval must bind the specific user, asset, network, destination and amount. If one program can change the destination and also mark the request approved, control of that program gives an attacker control of the approval too. The receiving component needs to check the content against an independent trusted source. Public material does not identify Bitget's internal fields or verification scheme.

Bitget's latest explanation says its investigation has ruled out private-key compromise. Mandiant's earlier report attributes the absence of observed key-compromise evidence to Bitget. Both statements concern the keys. A blockchain accepting a correctly signed transaction cannot check whether an exchange customer really requested that withdrawal. The backend must establish that intent and pass the checked payment content to the asset-moving components. If an attacker controls the preceding authorization information, protecting the key alone leaves this route open.

Some requests failed. SlowMist records later attempts to change withdrawal records directly in the wallet database and invoke local tasks: two fabricated BTC orders entered processing and returned errors, after which the attacker kept inspecting logs and order status. The report does not confirm completed transfers for those two orders.

4 Transfers continued after the anomaly was detected

SlowMist's earliest verified transfer was 93 TRX received by an attacker address at 02:31:00 on September 25, Beijing time. Eleven seconds later, the Ethereum receiving address obtained 0.84 ETH. Its compiled transfer records run through 05:23:11, approximately two hours and 52 minutes across multiple chains. A small beginning followed by multi-chain outflows is the published sequence. Establishing a specific intention to test controls would require the corresponding program and operator records.

Both Bitget's initial announcement and Mandiant place detection at 02:31. The exchange's later response timeline adds several distinct events: at 03:05, reconciliation found a significant discrepancy and the risk system automatically blocked withdrawal requests across the platform; containment began at 03:40; at 04:40, with key compromise still under consideration, funds began moving to cold wallets; at 05:44, wallet withdrawal services, including signing services, were shut down and related access isolated. All times here have been converted to Beijing time to keep UTC and UTC+8 from producing a false sequence.

Withdrawal requests were blocked at 03:05, yet funds continued moving afterward. The public record does not map those later transfers to their internal routes. Closing a customer-facing entrance can leave questions about executable queued jobs and direct downstream calls from a compromised server. Those paths need checking before the delay can be attributed to a particular control.

Before withdrawals reopen, these paths can test whether isolation is complete: a normal request should succeed, while an expired approval, altered destination or revoked calling identity should cause rejection before payment. Old identities and old tasks left in the queue must also lose the ability to pay. Check the result at the actual asset-moving operation; an alert alone does not confirm that a payment was stopped.

5 The funds and the services that have reopened

The initial announcement estimated $351.6 million. The September 25 update raised this to approximately $387.5 million, explaining that Zcash and TRON assets omitted from the first count had been added. The explanation updated on September 30 lists about $388 million and continues to attribute the figure to reconciliation and classification of the original incident. These are the exchange's published US-dollar-equivalent totals across several assets; subtracting a receiving address's current balance, or repricing it at today's market rates, would not calculate the amount recovered.

Bitget published primary receiving addresses and a fund-tracing dashboard. Its named EVM recipient is 0x770b10b273fc44fe9197d6bf20f145c2e98463ee. Address tracing helps platforms recognize incoming funds. Freezing restricts their movement at some point; returning assets takes further action and confirmation. Bitget says some assets have been frozen, but the reviewed notices provide no complete, reconcilable total of funds returned. The public address API returns address sets grouped by chain and cannot itself serve as a recovery ledger.

As of 16:25 UTC on September 30—00:25 on October 1 in Beijing—the following specific withdrawal-reopening notices were available. Each entry includes only the networks expressly covered by that notice; availability on other routes must be checked on the platform:

• BTC: the Bitcoin network reopened in a September 28 announcement; a separate BSC notice followed on September 30.
• ETH: the September 29 notice covers Ethereum, BSC, Arbitrum One, Base and Optimism.
• USDT: the September 30 notice covers Ethereum, BSC, Solana and Tron.

Other assets, fiat withdrawals and P2P remain scheduled for October 2 at 08:00 UTC, or 16:00 in Beijing. Customers should check their particular asset and intended network. There is no special early-access route offered by a “recovery agent.” Messages asking for a payment, password, verification code or seed phrase to assist recovery should be checked through official channels.