Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M

Root Cause Disclosed: A Third-Party Security Product's Zero-Day

Cryptocurrency exchange Bitget disclosed on September 28, 2026 that the attacker behind its roughly $388 million theft did not steal a private key or breach an employee account directly — they exploited a zero-day vulnerability in a third-party security product the exchange relied on internally. According to CEO Gracy Chen, that flaw gave the attacker a foothold in an internal management system, which was then used to obtain high-level, legitimate-looking credentials and forge withdrawal commands that Bitget's own wallet backend treated as authentic. CosmicBytez Labs has covered the breach's discovery and impact as they developed; this article focuses specifically on the root-cause mechanics Bitget confirmed this week.

Incident Details

How the Attack Worked

A Flaw in Security Tooling, Not the Exchange's Core Wallet Code

Chen's account inverts the assumption many observers made in the days after the breach — that Bitget's own transaction-signing or wallet-approval logic had been compromised. Instead, the entry point was a security product supplied by an outside vendor and deployed inside Bitget's environment, presumably to help protect the very systems it ended up exposing. Bitget has not named the vendor or product, and no CVE identifier has been made public. The company says it has since patched the flaw, but the lack of vendor attribution leaves other exchanges unable to independently check their own exposure to the same product.

From Zero-Day to Forged Withdrawals

Exploiting the flaw reportedly gave the attacker access to an internal management system, from which they obtained legitimate, high-level credentials rather than needing to steal a private signing key. Chen said the attacker then used those credentials to insert fraudulent withdrawal commands directly into wallet-related backend services, disguising the activity as routine administrative operations. Because the commands carried valid credentials and looked like normal internal traffic, Bitget's risk controls did not flag them as anomalous at the point of execution.

Testing the Controls Before the Main Theft

Before moving large sums, the attacker ran two small test transfers — 0.184 ETH and 193 TRX — at approximately 18:31 UTC on September 24. Both stayed under Bitget's automated risk-control thresholds and triggered no alert, effectively confirming that the forged commands would execute cleanly. Roughly 30 minutes later, the attacker escalated to 17 large transactions spanning eight blockchains, draining hot and warm wallet balances totaling close to $361 million in that window alone, with the fuller tally across all affected assets reaching Bitget's reported $388 million figure.

Covering Tracks

Chen described trace deletion as "the trickiest part" of unraveling the incident: after executing the fraudulent transfers, the attacker deleted logs and records associated with the forged commands, complicating Bitget's internal reconstruction of exactly how each transaction was authorized. Despite that, Bitget's reconciliation system caught the discrepancy within seven minutes of the first large transfer — at 19:05 UTC — and the platform's risk system blocked all user-initiated withdrawals shortly after, limiting further exposure.

Attribution

Bitget has stopped short of formally naming the group responsible pending a fuller incident report, but Chen said investigators believe it is "the same group of people" linked to prior large-scale crypto thefts attributed to North Korea. Blockchain analytics firm TRM Labs identified overlaps consistent with TraderTraitor, a threat cluster the U.S. government has previously tied to North Korean state-sponsored operations, though Bitget stopped short of a firm public attribution. Investigators are also examining IP infrastructure and VPN usage patterns for further corroboration.

Impact Assessment

Recommendations

For Exchanges and Security Teams

• Inventory and risk-assess every third-party security product with privileged internal access — endpoint agents, key-management add-ons, and internal admin tooling all expand the attack surface and deserve the same scrutiny as custody infrastructure itself.
• Don't let credential validity substitute for behavioral anomaly detection. This attack succeeded because forged commands carried legitimate credentials; risk engines that only check "is this credential valid" rather than "is this behavior normal for this actor" will miss similarly disguised abuse.
• Harden log integrity separately from the systems being logged. The attacker's ability to delete traces of its own commands significantly slowed incident response — write-once or externally replicated audit logs would blunt that tactic.
• Add independent, out-of-band verification for high-value withdrawals, as Bitget says it has now done, so that a single compromised internal path cannot unilaterally authorize large transfers.

For Third-Party Security Vendors

• Expect increased customer pressure for vulnerability disclosure timelines and patch SLAs following incidents like this one — exchanges will increasingly demand transparency into how quickly zero-days in security tooling are identified and fixed.
• Publish CVEs and advisories promptly once a flaw is confirmed and patched, so downstream customers running the same product can verify their own exposure rather than relying on a victim's indirect disclosure.

For Bitget Users

• No action is required to protect account balances — Bitget states user funds were not directly altered and the Protection Fund is intended to cover the shortfall in full.
• Be alert to phishing exploiting this incident, including fake "compensation" or "verification" links impersonating Bitget support channels.
• Follow official Bitget channels for the latest on withdrawal restoration and any updates to the formal incident report.

Key Takeaways

1. The intrusion began with a zero-day in a third-party security product, not a compromised private key or a direct breach of Bitget's own core wallet code.
2. Stolen high-level credentials, not stolen keys, drove the theft — the attacker forged withdrawal commands that Bitget's backend treated as legitimate.
3. Small test transfers preceded the main theft, confirming the forged commands would bypass risk controls before the attacker moved roughly $361–388 million across eight blockchains.
4. Deliberate log deletion slowed Bitget's forensic reconstruction, even though automated reconciliation caught the anomaly within seven minutes.
5. Bitget has not named the vulnerable vendor or product, leaving other platforms unable to independently verify exposure to the same flaw.
6. Attribution points toward North Korea, with TRM Labs flagging overlaps with the TraderTraitor cluster, though Bitget has not issued a final, formal attribution.

Sources

• The Hacker News — Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M
• The Block — Bitget attacker tested risk controls with small transfers before $388 million theft, CEO says
• Cointelegraph — Bitget Reveals New Details of $388M Crypto Hack