Bitget's breach: how forged withdrawals reached the wallets

1 The compromised system belonged to the exchange

Two products need separating first. 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 separate, non-custodial Bitget Wallet uses different infrastructure and was not involved, according to the company. Which product a person uses, and who controls the assets, changes the practical consequence.

The disclosed control points are third-party security appliances, a production wallet job server and the withdrawal software running there. Appliance vendors, vulnerability identifiers, internal interfaces and risk-field names remain unpublished; the reports cannot support a general patch checklist for other operators. 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. These are the exchange's reported response actions. The two interim forensic reports do not provide a complete acceptance test of the repaired environment.

For a customer, the immediate question is whether their assets can be withdrawn. Bitget says account balances will bear no loss, with its Protection Fund covering the financial impact, and is reopening withdrawals in stages. The asset and network announcements are collected at the end of this article. A displayed balance, an available withdrawal route and recovered stolen funds answer different questions.

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.

Applications often obtain database connection settings from environment variables. Code running with the process's access can potentially read the same password. The report does not disclose that account's full privileges, so its maximum authority remains unknown. Once a credential gives an attacker access to another system, however, the intrusion can extend to services that trust it. The useful question is what the credential can actually reach. The label “security appliance” tells us the device's intended job, not the reach of its permissions.

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 access-management problem is concrete: authority available on a security appliance extended to production wallet tasks. Adding a security product can improve detection and administration while also adding another actor that runs code, stores credentials and connects to other machines. Its permitted destinations and whether its credentials can reach wallet servers need checking when the product is introduced. Patching the initial entry point addresses how the attacker first entered. Already issued credentials and established access still need revocation in their own right.

3 A backend machine began requesting the attacker's withdrawals

Server access still had to become a movement of funds. SlowMist recovered a highly customized withdrawal tool from deleted files. Its report describes three linked actions: forging risk-control parameters, constructing withdrawal requests and invoking the withdrawal process. Host logs place the malicious program's execution and theft activity at 01:49 on September 25, Beijing time. At that point the compromise had acquired a business capability: it could create a withdrawal request that downstream software would process.

The risk fields are not named publicly. We cannot tell whether the tool changed an approval status, a verification result or some other business value. The recovered software was tailored to wallet logic and could call the existing withdrawal process. That makes the origin of a request, and who checked its payment content, central to the investigation.

Consider the design question in a typical withdrawal system. A request needs to bind a user, asset, network, destination and amount; any approval must refer to that specific content. If the sending component can change both the destination and the information saying it was approved, the receiver needs an independent trusted check. Otherwise, two apparently separate fields are assertions from the same compromised program. This is an authorization design worth testing after the incident; public material does not establish which fields or verification scheme Bitget used internally.

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.

The tool also had observable limits. 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; the attacker continued inspecting logs and order status. Some requests therefore still failed, and the public report does not confirm completed transfers for those two BTC 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.

Reconciliation alerts, request blocking and stopping signatures operate at different places. If the customer-facing withdrawal entrance is closed, operators still need to know whether backend jobs remain executable, how queued work is invalidated and whether a compromised server can call downstream services directly. The published timing makes those questions urgent. It does not map every transfer after 03:05 to a particular internal route, so the entire delay cannot be assigned to one switch.

A useful recovery test would establish that old identities, queued tasks and forged requests have lost the ability to cause payment. A legitimate customer withdrawal should succeed. The same content with an expired approval, altered destination or revoked calling identity should be rejected, with the outcome checked where funds actually leave. That test addresses the failure exposed here. Seeing an alert establishes only that abnormal activity became visible.

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.

The most meaningful developments from here will be reconcilable asset returns and verification that a compromised backend can no longer forge withdrawal authorization after the repair. The exchange is progressively reopening services. Who independently approves the request that lets a wallet pay remains a question worth following.