How they got in: Bitget, September 2026

A note on sources, and what this piece is.

This piece reads three kinds of material. The first is Bitget's own public statements [3][4][5][6][7]. Bitget's incident page displays September 30 at 00:00 UTC as its last update; that displayed timestamp does not establish when each statement on the page was added [7]. The second is two reports that became available on September 30 [6]: a Mandiant status report with a cover date of September 28 [1], and a SlowMist progress report current as of September 29 [2]. The third is named press and analyst reporting [8][9][10] and, for the short comparison, cited public accounts of earlier incidents [17][18][19].

Kahu Labs did not take part in the investigation. We haven't seen Bitget's systems or logs, and we didn't trace the transactions ourselves. When a report says something was verified, the verification is the investigators'. The reports are Mandiant's and SlowMist's work, and Bitget's statements are Bitget's account. The reading and the recommendations here are ours.

Both investigations were still going when the reports were written [1][2]. Treat them as a snapshot. Where they differ, we show both versions and don't choose.

Every statement in /what failed carries one of three labels. Source statement: means an explicitly attributed statement by Mandiant, SlowMist, or Bitget, not independent confirmation by Kahu Labs. Public reporting: means a named press or analyst account, or a cited public account of an earlier incident. Our inference: means Kahu Labs' reasoning and recommendations from the record. The reports describe what happened, and they don't list Bitget's controls. So our recommendations are suggestions for any exchange, and a crossed boundary in this piece doesn't mean the reports found a missing control.

The reports call the two security products Product A and Product B, and neither names the attacker [1][2]. We follow them. Public reporting: Bitget CEO Gracy Chen has said in public that a North Korean group was likely behind the theft, and Elliptic assesses a link to North Korea as "highly likely," citing, among other things, on-chain links to earlier DPRK-attributed thefts [10]. Those are claims by Chen and by Elliptic. Bitget's Academy explanation says it will not speculate on attribution without verified investigative findings [6], and we don't name anyone either.

A note on dates. The reports use UTC+8, which puts the theft on September 25 [1][2]. Bitget's notices use UTC, where the same moment falls on the evening of September 24 [4][6]. It's one event. Times below are UTC+8 unless marked.

/what happened

The doors.

Think of every system a company runs as a door. Known as: attack surface. The doors in this story were two third-party security products in Bitget's environment [1][2][3]. Our inference: Security tools often need wide reach and high privileges to do their job, which makes them worth attacking. The reports do not describe the products' full intended roles or access permissions. Mandiant does report that the attacker used appliance B to reach the production wallet job server [1].

First, a word on wallets. Exchanges typically keep most funds offline in cold wallets and a working balance online in hot wallets, so withdrawals can go out quickly. Warm wallets sit in between. Known as: hot, warm and cold wallets. Bitget says it runs all three tiers and that only part of the hot and warm layers was affected [4][6].

01 Activity on Product A, from August 31.

SlowMist's earliest sign of malicious activity, in the logs available to it, is August 31 [2]. SlowMist calls the flaw affecting a service on one Product A node a zero-day [2]. The term generally refers to exploitation of a previously unknown vulnerability [20]. The report does not disclose when the vendor learned of this flaw or when a fix became available. The attacker ran a hidden script under that service, used a command to read an environment variable holding a database password, and connected to the database [2]. SlowMist saw similar hidden-script activity on two other nodes, on September 23 and September 25 [2]. It says these findings show the affected services had been compromised before any assets were transferred out [2].

An environment variable is a setting a program can read while it runs. Here, one held a password. The report doesn't say which database the password opened, or whether it mattered later [2].

August 31 is the earliest activity SlowMist found in the material it was given, and the report doesn't call it the first day of the intrusion [2]. It also doesn't say whether older logs exist.

02 A second product, and an employee's identity.

Mandiant's forensic findings indicate that on September 24 the attacker gained unauthorized privileged access to both appliances, A and B [1]. Mandiant says the attacker installed a web shell on appliance B and established a command-and-control connection [1]. Known as: web shell, a small program that lets someone send commands to a server through a web interface. Known as: command and control, or C2, for the steering channel.

SlowMist describes Product B in different terms. In the early hours of September 25, the attacker accessed Product B's management platform using an internal employee's identity [2]. Starting at 00:07, the attacker made three attempts in a row to insert system commands into a task's parameters so the platform would write malicious files [2]. The attacker then submitted code through the platform's web execution endpoint, attempting to change server settings, write a file for relaying communications, and upload and assemble malicious program files in batches [2]. SlowMist describes these as attempts and doesn't say which ones succeeded.

Neither report says how the attacker came to be using that employee's identity, or whether Mandiant's web shell and SlowMist's account describe the same activity [1][2]. Bitget's own summary says the attacker may have used a flaw in a third-party security product to obtain high-level internal credentials [6]. Its incident page puts it without the hedges: a zero-day in a third-party security product gave the attackers access to critical internal management systems, and forged identity information looked genuine, so the access registered as normal logins [7]. Neither report connects Product A to Product B.

03 From an appliance to the wallet job server.

Mandiant says the attacker used that persistent access on appliance B to move to Bitget's production wallet job server and deploy malicious packages there [1]. Known as: lateral movement, getting from one compromised system to the next. Mandiant's summary is that the attacker compromised network and security appliances and used them to distribute malicious packages and gain control over the wallet job server [1].

SlowMist names a wallet application host among the affected systems and says it is still investigating how the attacker moved between them [2]. The reports don't say whether the wallet job server and the wallet application host are the same machine.

04 A withdrawal tool built for Bitget's system.

SlowMist recovered a highly customized withdrawal tool from files the attacker had deleted [2]. It was tailored to the wallet system's withdrawal logic. It forged risk-control parameters in its code, built withdrawal requests, and invoked the withdrawal process [2]. Known as: risk controls, the checks a system runs to decide whether a withdrawal looks safe. A host log shows the malicious program starting to run and steal at 01:49 [2]. The report doesn't publish which parameters were forged or how Bitget's checks work, so we won't guess at them.

Bitget's own account is close to this. It says the attacker appears to have sent fraudulent withdrawal commands to the wallet system, which carried out transfers that bypassed existing risk controls [6]. Its incident page adds that the attackers wrote forged withdrawal commands directly into the wallet system, which processed them as normal withdrawals, bypassing risk-control verification before withdrawal records were generated, and that the attackers deleted traces after the transfers [7]. Our inference: The record points at the path that requests withdrawals more than at key storage. That reading leans on Bitget's statement that key compromise has been ruled out to date [6], and the reports don't describe how Bitget's signing works.

05 Transfers over almost three hours.

The earliest transfer SlowMist has verified on-chain arrived at 02:31:00: 93 TRX to the attacker's address, then 0.84 ETH on Ethereum 11 seconds later [2]. The records it compiled run to 05:23:11 the same morning, about 2 hours and 52 minutes, across several blockchains [2]. Mandiant, relaying Bitget, says Bitget's security monitoring detected the unauthorized transfers at 02:31, and that they ran alongside legitimate internal wallet operations on Ethereum until about 05:23 [1].

After the transfers had begun, the attacker also tried to change withdrawal records directly in the wallet database and to start withdrawal tasks on the host itself [2]. Two fabricated BTC withdrawal orders entered processing and returned errors. The logs then show the attacker reviewing logs, checking order status, and trying again, all after 05:22 [2]. The report does not explain why the two BTC orders returned errors or establish which control, if any, caused those responses.

06 What Bitget did.

Bitget's own timeline, updated September 30, gives its response in UTC [6]. Converted to UTC+8, it reads like this. At 03:05 its reconciliation system flagged a significant discrepancy, and its risk-control system automatically blocked withdrawal requests across the platform. At 03:14 Bitget raised its highest-level emergency response, and containment began at 03:40. At 04:40, because key compromise hadn't yet been ruled out, the wallet team started moving funds to cold wallets. At 05:44 Bitget shut down wallet withdrawal services, signing included, and isolated withdrawal-related access [6].

Since then, Bitget says, it has isolated the affected systems, remediated the underlying vulnerability, revoked and reissued internal login credentials, restructured access to highly sensitive systems, and started requiring multiple approvals for critical operations [6]. It also says it notified the vendor and disabled the affected function pending completion of a fix [6]. Its incident page says the relevant vulnerabilities have been patched and the vendor is assisting with remediation [7]. From these statements we can't tell whether the vendor has shipped a fix. Bitget reported the incident to law enforcement on September 25 (UTC) and notified financial intelligence units [6]. It says its User Protection Fund covers the loss; its first notice put the fund at over $464 million [4][6].

/the timeline

Source statement: Bitget's published timeline places the automatic withdrawal block at 03:05 and the shutdown of signing services at 05:44 [6]; SlowMist's compiled transfer records end at 05:23:11 [2]. Public reporting: Bitget's CEO told The Block the 03:05 block covered user-initiated withdrawals [8]. Our inference: These timestamps do not establish when the underlying transactions were requested, signed, or broadcast, or which containment action ended the unauthorized transfers. A backend route outside the user-facing withdrawal block is a possibility to test; the reports do not establish it.

/what the two reports say, and where they differ

The two dates are more than three weeks apart, and they describe different things: when Mandiant's forensics place privileged access to the appliances, and the earliest activity SlowMist found in the logs it had [1][2]. Neither report presents its date as the start of the whole intrusion, and neither explains the other.

The Product B accounts differ in kind. Mandiant describes a web shell and remote control; SlowMist describes an employee's identity, attempted command injection, and a web execution endpoint [1][2]. The reports don't say whether these are the same activity described at different levels of detail.

Mandiant's "malicious packages" and SlowMist's withdrawal tool might be the same thing or might not [1][2]. Neither report says.

Bitget's campaign page says the attackers "did not use common viruses or malware" and describes use of legitimate identities and routine operational procedures [7]. Mandiant describes a web shell and malicious packages [1], and SlowMist describes a hidden script and a custom withdrawal tool it calls a malicious program [2]. Bitget's page also says an investigation has confirmed the full attack chain [7], while SlowMist's report says it is still investigating movement between systems [2]. Bitget's campaign page uses different wording about malware and investigation completeness. Its scope and update history are not clear enough to establish a direct contradiction with the earlier reports. We retain each account with its source and date, and treat the detailed attack chain as unresolved in the public record.

Bitget's own statements differ on detection. Its first notice says its security systems detected unauthorized transfers at 18:31 UTC, which is 02:31 UTC+8 [4], and its incident page says the same [7]. Its updated timeline lists 18:31 UTC as the time of the first unauthorized transfers and puts detection at 19:05 UTC, or 03:05 UTC+8 [6]. We don't know which signal each account refers to, and we don't treat the difference as a measure of response time.

Public reporting: Chen told The Block the first two transfers were small tests below the risk-control threshold that raised no alerts, and gave them as 0.184 ETH and 193 TRX [8]. SlowMist gives 93 TRX and 0.84 ETH [2]. Public reporting: Chen also put 17 larger transactions, worth about $361 million, between 02:58 and 04:09 UTC+8 [8]. SlowMist's compiled records run to 05:23:11 [2], and the two windows may cover different sets of transfers. We can't tell from public material which figures are right, and nothing below depends on them.

The loss figure moved too: $351.6 million in Bitget's first notice [4], about $387.5 million after a fuller count that added Zcash and TRON assets [5], and about $388 million on its Academy page [6]. Bitget's incident page calls $388 million final verified figures [7], while the Academy page says the estimate may be updated [6]. Mandiant gives Bitget's estimate as a range of $351.6 million to $387.5 million [1].

/what failed

Ten blocks follow. Most name a boundary the record shows the attacker got past; the last two cover the time it took to stop signing and the limits of the logs. Each block says what the record shows and why it matters, and adds a practitioner layer. Every statement carries its own label. The reports show outcomes and don't list Bitget's controls, so a crossed boundary here doesn't mean a control was missing. Every recommendation is our inference.

/what held

Some things held, according to the record.

Bitget says its cold wallets across all chains were not affected, and Mandiant relays the same [1][6]. The reports don't say which control kept that boundary intact. Bitget also says private-key compromise has been ruled out based on its investigation to date [6].

Bitget's reconciliation system flagged the discrepancy, and its risk-control system automatically blocked withdrawal requests across the platform, at 03:05 by Bitget's timeline [6]. Mandiant, relaying Bitget, puts detection by Bitget's security monitoring at 02:31 [1].

Two fabricated BTC withdrawal orders entered processing and returned errors [2]. The report doesn't say why, so we don't credit a control for it.

SlowMist recovered the custom withdrawal tool even though the attacker had deleted it [2]. Bitget Wallet, a separate non-custodial product on separate infrastructure, was not affected, Bitget says [6].

Bitget posted a public notice, named its outside investigators, and made both reports available [3][4][5]. It says its User Protection Fund, which held over $464 million at the time of its first notice, covers the loss [4][6].

/lessons for other exchanges

Questions to ask this week. Each points back to a block above.

1. List every security appliance and management console that can reach a wallet or signing host, directly or through identity and deployment systems. For each one, who can log in, from where, with what kind of MFA, and what can it run? (Blocks 01, 04, 05 and 06. Edge-device guidance [11][12].)
2. If one of those tools had an unknown flaw today, what could its service account read and use? Check for passwords in environment variables and config files, and what each one opens. (Blocks 02 and 03. ATT&CK T1552 [13].)
3. Can your security tools run commands or code on the machines they manage? If so, who can create a task, and is every task logged somewhere the tool can't rewrite? (Block 04.)
4. Is there any network path from an appliance network to a wallet job server? Test it from the appliance side. (Block 06.)
5. A new program starts on your wallet job server at 01:49 on a Friday. Who gets paged, and how fast? (Block 07.)
6. Assume a withdrawal worker is compromised. What can its credentials do, and could it produce every piece of evidence needed to approve its own withdrawal? (Block 08. CCSS 1.05.8 [14]; OWASP [15].)
7. Where do your withdrawal risk checks get their inputs? Can the host that builds a withdrawal change them? (Block 08.)
8. Would two small transfers below your alert threshold, from two hot wallets on two chains, show up anywhere? (Block 08. Public reporting [8].)
9. How long does it take, in practice, to stop unauthorized requests and new hot-wallet signatures, including queued approvals, retries, and direct signer calls? Track signed-but-unbroadcast transactions and pending broadcasts separately. When did you last drill it? (Block 09.)
10. During an incident, does automatic top-up keep refilling a hot wallet that's being drained? (Blocks 08 and 09.)
11. How far back do your appliance logs go, where do they live, and who can delete them? (Block 10. [11][12].)

/what we still don't know

The reports leave these open. We list them as unknowns.

How the attacker first reached the Product A service, and whether that service was reachable from the internet.

How Product A and Product B relate, and whether the database password from Product A mattered later.

How the attacker got from appliance B to the wallet job server. SlowMist says it's still investigating how the attacker moved between systems [2].

How the attacker came to be using an employee's identity. Bitget ties it to credentials stolen through the zero-day [7]; the reports don't say.

Whether Mandiant's malicious packages and SlowMist's withdrawal tool are the same thing, and whether the wallet job server and the wallet application host are the same machine.

Which signal each detection time refers to, and why transfers continued after the 03:05 block.

What share of the hot and warm wallet infrastructure was affected. Bitget's latest figure covers transfers from 12 hot or warm wallet addresses [6].

Which Ethereum operations before 05:23 were Bitget's own, including its moves to cold wallets from 04:40.

Why the two fabricated BTC orders returned errors.

Whether anything happened before August 31 that the reviewed logs don't show.

How Bitget's signing and approval system is built, and which specific checks the forged commands got past. Bitget says only that they bypassed risk-control verification before withdrawal records were generated [7].

Which products these are, which flaw was used, and whether the vendor has shipped a fix. Bitget says the affected function is disabled pending one [6].

/how we'll update this

Both reports are preliminary. When Bitget, Mandiant, or SlowMist publishes a final report or corrects a figure, we'll update this post, note the date and what changed at the top, and keep the earlier wording in a change log at the bottom. The original evidence was collected on October 1, 2026; we reviewed the public sources again on October 2, 2026.

Bitget says it will release a formal security report with more technical detail [7]. When it does, we'll read it the same way.

If you run security at an exchange and want to talk through any of this, write to hello@kahulabs.com.