Bitget Says $387.5 Million Theft Traces Back to a Zero-Day in Third-Party Security Products

Bitget Confirms Zero-Day in Security Tooling Behind $387.5 Million Heist

Cryptocurrency exchange Bitget revealed on September 30, 2026, that the attackers behind a $387.5 million theft disclosed the previous week broke into its systems by exploiting a zero-day vulnerability in two unnamed third-party security products used as internal security appliances. Bitget CEO Gracy Chen said the flaw gave the attacker high-level internal credentials, which were then used to forge withdrawal instructions that Bitget's own backend systems treated as legitimate, draining funds from hot and warm wallets across seven blockchains. Investigators from Mandiant and blockchain-security firm SlowMist supported the incident response; SlowMist's analysis traced the earliest malicious activity to August 31, 2026 — more than three weeks before the theft itself. Chen said the company suspects the intrusion was carried out by the same North Korea-linked actor group behind earlier crypto-exchange heists, citing "IP behavior patterns and on-chain analysis" as supporting evidence; blockchain analytics firm TRM Labs has separately flagged overlaps between wallets used in this incident and those tied to the North Korean group known as TraderTraitor. Bitget has not named the compromised security vendor(s), and a company spokesperson was unable to provide further detail on which specific products were affected.

How the Breach Unfolded

Initial Access via a Security Appliance Zero-Day

According to SlowMist's investigation, the intrusion began on August 31, 2026, when a service running on one node of a compromised third-party security appliance was affected by a zero-day flaw. The attacker used this foothold to run a hidden script that read a database password directly out of an environment variable, then used those credentials to connect to an internal Bitget database. Follow-up traces of the hidden script were observed by investigators on September 23 and September 25.

Escalation to a Second Product and Lateral Movement

The attacker subsequently obtained access to the management platform of a second third-party security product — referred to by SlowMist only as "Product B" — reportedly using an internal employee's identity. That persistent access was then used to move laterally to Bitget's production wallet job server, where the attacker deployed malicious packages and a custom withdrawal tool. Bitget said the compromise ultimately yielded high-level internal credentials rather than access to cold storage or private key material.

Forged Withdrawals and the Theft Window

With privileged internal access established, the attacker inserted fraudulent withdrawal commands into wallet-related backend services. Because those commands originated from an internally trusted system, Bitget's risk-control checks treated them as legitimate. SlowMist's timeline places the fraudulent transfers between roughly 02:31 and 05:23 UTC+8 on September 25 (equivalently, starting around 18:31 UTC on September 24) — a theft window of nearly three hours spanning seven blockchains. Bitget said it detected the activity and suspended withdrawals the same day, then engaged Mandiant and SlowMist to investigate before disclosing full details on September 30.

Impact Assessment

Recommendations

For Cryptocurrency Exchanges and Custodians

• Treat third-party security appliances and management consoles as high-value targets in their own right, not just as protective layers — apply the same patch-latency and access-segmentation scrutiny to them as to production trading systems.
• Avoid storing database credentials in environment variables readable by any compromised service account; use short-lived, scoped credentials pulled from a secrets manager instead.
• Require independent, out-of-band verification for withdrawal instructions originating from internal management systems, rather than trusting internal-network origin as a proxy for legitimacy.
• Segment wallet job servers and production signing infrastructure from general internal networks so that lateral movement from a compromised security appliance cannot directly reach hot-wallet withdrawal paths.

For Security Teams Running Third-Party Security Products

• Maintain an inventory of every security appliance with privileged network or credential access, and monitor vendor advisories closely given how often these products themselves become the entry point rather than the defense.
• Watch for anomalous outbound connections or hidden scripts on security-appliance nodes — the initial compromise here persisted for over three weeks before the theft occurred.
• Log and alert on any script or process reading credentials from environment variables outside of expected startup sequences.

For Bitget Users and Affected Token Holders

• Monitor official Bitget communications and the exchange's recovery portal for updates on staged withdrawal reopening and any compensation timeline.
• Be alert to phishing attempts impersonating Bitget support or "recovery" services in the wake of the disclosure — large publicized thefts reliably draw opportunistic scams targeting affected users.
• Where possible, avoid leaving large balances on any exchange's hot wallet infrastructure long-term, regardless of which platform is used.

Key Takeaways

1. Bitget confirmed that the $387.5 million theft disclosed last week stemmed from a zero-day vulnerability in third-party security products, not a flaw in Bitget's own exchange code.
2. The intrusion began as early as August 31, 2026, with the actual fund theft occurring roughly three weeks later, over a window of about three hours on September 24–25.
3. The attacker escalated from an initial security-appliance compromise to a second security product's management platform, then moved laterally to Bitget's production wallet job server.
4. Stolen funds came from hot and warm wallets only across seven blockchains; Bitget says cold wallets and private keys were not compromised.
5. Bitget suspects North Korea-linked actors, with TRM Labs flagging possible overlap with the group known as TraderTraitor; formal attribution has not been finalized.
6. Bitget has not named the compromised vendor(s), launched a 5% Recovery Bounty Program, and is relying on its Protection Fund to cover user losses, while its CEO says she is "not very optimistic" about fully recovering the stolen assets.

Sources

• BleepingComputer: Bitget hacked via zero-day in third-party security products
• The Hacker News: Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M
• Cointelegraph: SlowMist Traces Bitget Hack Activity to Zero-Day Exploit