Bitget hack: how a flaw in a security product led to a $388M theft

What happened in the Bitget hack

The Bitget hack took about $388 million from one of the world’s larger crypto exchanges in a single evening. According to Bitget’s own incident timeline, unauthorised transfers began at 18:31 UTC on 24 September 2026. The exchange’s reconciliation system flagged a discrepancy at 19:05 UTC and withdrawals were blocked.

The money left 12 addresses tied to Bitget’s hot and warm wallets. It moved across a long list of chains, including Ethereum, the XRP Ledger, TRON, Arbitrum, Base and BSC. Cold wallets were not touched, and Bitget says user account balances were not affected.

The detail that matters most about the Bitget hack is how the attacker got in. Bitget says they exploited a vulnerability in a third-party security product to obtain high-level internal credentials. They then used those credentials to send fraudulent withdrawal commands to the wallet system.

How the Bitget hack started: a security tool

Bitget has not named the product or its vendor. Its CEO, Gracy Chen, said the vendor has been told and that the flaw is fixed. So we know the category but not the brand.

That is still enough to learn from. Security products sit in privileged places. They see traffic, hold service accounts and often run with wide access so they can do their job. A flaw in one of them hands an attacker the same reach.

Teams harden their applications, then trust the tools around them without much scrutiny. The tools that guard the estate rarely get tested as targets in their own right. Testers know this gap well, and so do attackers.

The Bitget hack also shows how little warning a firm may get. A flaw in a trusted product can turn into a full breach within an hour. There is no phishing email to spot and no malware to catch. The attacker walks in through a door the firm itself opened.

Legitimate credentials beat the alarms

Chen said the attacker “used legitimate credentials” and disguised their activity as routine administrative operations. That part should worry any security team running a crypto exchange or any other firm.

According to reporting, the attacker began with two small test transfers that stayed below risk-control thresholds. Larger transfers followed and got past those controls. The activity looked like an admin doing admin work, so the usual rules had little to trigger on.

Once an attacker holds valid admin credentials, tools that hunt for known bad code struggle. The question shifts from “is this malicious?” to “should this account be doing this, right now, at this size?” Few firms have tuned their monitoring to answer that. Most alerts still fire on the content of an action, not its context.

The response, and what it tells us

Bitget’s fixes read like a checklist for any firm holding high-value assets. It isolated the affected systems, revoked and reissued internal credentials, and restructured access so that sensitive systems need multiple approvals. It also added independent verification for withdrawals.

The exchange brought in Mandiant and SlowMist for the investigation and notified law enforcement. It set up a recovery bounty of 5% for anyone who helps freeze or recover funds. Withdrawals came back in phases, starting with Bitcoin on 28 September.

On attribution, Chen said North Korea is suspected because of preliminary IP indicators. She also stressed that those indicators are still being assessed. Treat the attribution as a lead, not a finding. The story of this hack will keep changing.

What your business can take from it

You may not run a crypto exchange, but the failure mode applies to any firm with valuable systems behind admin credentials. A few practical steps follow.

• Inventory your security tools and treat each one as an attack surface. Ask what credentials it holds and what it can reach.
• Limit standing privilege. A stolen admin login should not be enough to move money or wipe data on its own.
• Require a second, independent approval for high-value actions, and keep that check on a separate system.
• Watch for context, not just content. Flag unusual timing, size and sequence, even from valid accounts.

Credential exposure through trusted software is a recurring theme. We covered a similar structural problem in our look at plugin credentials and the Gravity SMTP flaw. Both cases show how one privileged component can undo a lot of careful work elsewhere.

How to test for this kind of failure

Standard vulnerability scans will not tell you what an attacker could do with one stolen admin account. That needs a test that starts from the assumption of compromise. Our guide to internal versus external penetration testing explains why the internal view answers the question that matters here.

Ask the tester to include your security tooling in scope. See what a compromised console gives them, and whether your monitoring notices when they use it. If the answer is “nothing and no”, you have found your Bitget-shaped gap before someone else does.