Bitget’s Wallet Server Served the Attacker
Update: Bitget’s 20 October 2026 account puts final losses at approximately $388 million, across 12 addresses and 11 blockchains. It rules out private-key compromise, reports no unauthorised transfers after containment and confirms phased withdrawals were restored by 2 October. It attributes forged payout commands to stolen high-level credentials. These remain exchange statements, rather than an independent cryptographic audit.
The earlier fund-tracing notice gave $387.5 million, up from $351.6 million as accounting added Zcash and TRON transfers from the original incident. That revision was not evidence of a second breach.
The intrusion path
SlowMist’s report uses UTC+8. Logs first show hostile activity on 31 August, when a Product A service zero-day let hidden scripts read an environment variable containing the database password and access the database. Two further nodes showed similar scripts on 23 and 25 September. Early that day, an employee identity entered Product B’s management interface; attempts followed to inject commands, change configuration and plant files. This separate route does not show that both products had previously undisclosed flaws.
Mandiant’s interim findings describe unauthorised elevated control of two third-party security appliances (A, B) on 24 September. Appliance B had a web shell and command-and-control channel; lateral movement then reached the server coordinating production wallet jobs, where malicious packages were deployed and control obtained. Its background section reproduces the exchange’s private-key observation; it does not describe a separate audit of the cryptography.
Separate the milestones
Deleted files yielded a bespoke tool that replicated wallet logic, forged parameters for risk controls, constructed requests and invoked payouts. On 25 September, host execution began at 01:49; verified transfers span 02:31 to 05:23:11, about 2h52m.
Mandiant calls 02:31 UTC+8 detection. The exchange’s timeline dates the first unauthorised transfer to 18:31 UTC on 24 September, then discrepancy detection and automatic blocking to 19:05 UTC, equivalent to 03:05 UTC+8 the following day. The discrepancy needs reconciliation.
Automatic blocking differs from the later shutdown of withdrawal and signing services at 21:44 UTC. The last compiled transfer converts to 21:23:11 UTC that day, before shutdown. Neither record demonstrates transfers beyond that shutdown. A last compiled transfer is not necessarily the last attempted action.
Test the authority before the signature
Cryptographic key custody is only one part of a transaction boundary. The services allowed to request, approve or orchestrate a signature can be equally important. A validly authenticated command can still be malicious when the identity or system behind it has been compromised.
Security teams operating high-value automated transactions should ask:
- Which products and service identities can create or alter a withdrawal instruction?
- Can one credential reach the wallet workflow without an independent approval?
- Can a security appliance read credentials or reach production transaction systems?
- Does behavioural monitoring challenge a command that is technically valid but financially abnormal?
- Are third-party security products isolated from the most sensitive transaction systems?
- Can monitoring distinguish the first malicious execution, the first transfer, detection and automatic blocking?
The final technical report still needs to explain why the earlier controls trusted the commands and how the revised design blocks the same path. Financial reserves, service restoration and a completed security investigation remain different measures of recovery.
Restoration needs a separate receipt
The published restoration plan assigned BTC to 28 September, ETH to 29 September, USDT to 30 September, and other supported tokens, fiat and peer-to-peer services to 2 October, each at 08:00 UTC. The current account confirms completion.
Customers should verify availability only through the exchange’s official site or application, review recent sessions and API keys, and reject recovery messages asking them to transfer funds. Organisations holding operational funds on one exchange should confirm who can authorise an alternative route and how long the business can continue during a withdrawal freeze.
BlackTree has previously examined how cryptocurrency ownership can create exposure outside the wallet. The operational lesson is complementary: protecting private keys is not enough if compromised infrastructure can still request and authorise transfers.
Limits
The reports identify no product, vendor, actor, CVE or affected-version matrix. The exchange says its own environment was remediated and affected functionality disabled; this does not establish a fix for other customers of the unnamed product.
Both forensic accounts are interim. SlowMist warns that supplied material may be incomplete; Mandiant’s investigation remained ongoing. The exchange’s service restoration is a different claim from a complete, independent forensic account.
Sources
- Current exchange incident account.
- First forensic report, findings to 2026-09-29.
- Mandiant report, dated 2026-09-28.
- Fund-tracing notice, 2026-09-25.
- Restoration plan, 2026-09-26.
- Official release of both reports, 2026-09-30.


