Bitget’s $388 Million Breach Now Points to a Third-Party Security Product

The new evidence sharpens the central security question. The documented path ran through systems trusted to protect and operate the wallet environment, rather than through a confirmed theft of private keys. However, the statement that no private keys were compromised remains Bitget’s observation, reproduced in the background section of Mandiant’s report. It is not presented there as a separate cryptographic audit conclusion by Mandiant.

What Bitget now says happened

Bitget’s latest account puts the first unauthorised transfers at 18:31 UTC on 24 September, followed by discrepancy detection and automatic withdrawal blocking at 19:05. It says approximately $388 million was affected across 12 wallet addresses and 11 blockchains.

Bitget’s 29 September account said an attacker may have exploited an unnamed third-party security product, obtained high-level credentials and issued fraudulent withdrawal commands. The new reports substantiate the security-product path, but they do not support saying that both products were exploited through zero-days. SlowMist documents a zero-day affecting Product A and says Product B’s management platform was accessed with an internal employee identity. Mandiant documents unauthorised privileged access to both appliances without assigning the same entry method to each one.

A separate Bitget fund-tracing notice gives the more precise figure of $387.5 million. Bitget attributes the increase from $351.6 million to a fuller accounting of the original transfers, including Zcash and TRON assets, rather than a second breach. That explanation remains the exchange’s account. Mandiant’s background section uses a different detection time from Bitget’s public timeline.

The foothold may have existed for more than three weeks

SlowMist’s investigation report says the earliest malicious activity in the available logs dates to 31 August. A service on one Product A node was affected by a zero-day vulnerability. SlowMist says the attacker ran a hidden script under that service, read a database password from an environment variable and connected to the database. Similar hidden-script activity appeared on two other nodes on 23 and 25 September.

SlowMist separately says the attacker entered Product B’s management platform with an internal employee identity during the early hours of 25 September. The attacker attempted to inject system commands, change server configuration and place files through the platform. This is a second access path in the report, not evidence of a second zero-day.

Mandiant’s incident-response report says the attacker obtained unauthorised privileged access to security appliances A and B on 24 September. It found a web shell and command-and-control connection on appliance B, followed by lateral movement to Bitget’s production wallet job server. Mandiant says malicious packages were deployed and the attacker gained control of that job server.

A custom tool turned access into withdrawals

SlowMist recovered a highly customised withdrawal tool from files the attacker had deleted. It says the tool was built around the wallet system’s withdrawal logic, forged risk-control parameters, constructed withdrawal requests and invoked the withdrawal process. The host log places the malicious program’s execution at 01:49 on 25 September, UTC+8.

For 25 September in UTC+8, SlowMist’s on-chain review puts the first verified transfer at 02:31 and the last compiled transfer at 05:23:11, a span of approximately two hours and 52 minutes. Mandiant’s background section calls 02:31 the detection time. Bitget’s public timeline instead places discrepancy detection and automatic withdrawal blocking at 19:05 UTC on 24 September, equivalent to 03:05 UTC+8 on 25 September. The sources therefore use different detection times.

Automatic blocking was not the same event as the later shutdown of withdrawal and signing services. Bitget’s updated timeline places that shutdown at 21:44 UTC on 24 September. SlowMist’s last compiled transfer, equivalent to 21:23:11 UTC that day, precedes it. These records do not by themselves demonstrate transfers after that shutdown. The remaining detection-time discrepancy needs reconciliation, not an assumption that every containment milestone was simultaneous.

The real control test sits before the key

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.

What customers should do now

Bitget’s phased withdrawal schedule lists BTC for 28 September, ETH for 29 September, USDT for 30 September and other supported tokens, fiat and peer-to-peer services for 2 October, each at 08:00 UTC. The published timetable is not a substitute for checking actual availability in the official platform.

Customers should verify availability only through Bitget’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.

What remains unknown

The two security products and their vendors remain unnamed. No public CVE, affected-version matrix or vendor-wide remediation was identified. Bitget says the vulnerability was remediated in its own environment and affected functionality was disabled, but that does not establish a fix for other users of the unnamed product.

Both reports are interim. SlowMist says its analysis is based on supplied materials that may contain omissions, while Mandiant says its investigation is ongoing. Neither report establishes actor attribution.

Sources

• SlowMist, Bitget Security Incident Investigation Progress Update, findings current to 29 September 2026 and published in SlowMist’s repository on 30 September 2026.
• Mandiant, Bitget Incident Response Status Report, dated 28 September 2026 and publicly available on 30 September 2026.
• Bitget’s incident explanation and timeline, updated 30 September 2026.
• Bitget’s fund-tracing and revised-loss notice, dated 25 September 2026.
• Bitget’s phased withdrawal plan, dated 26 September 2026.
• Bitget, update on the SlowMist and Mandiant reports, published 30 September 2026.