Bitget’s $387.5M Hack: What the New Zero-Day Findings Mean

The most important new detail in the Bitget hack isn't the roughly $387.5 million loss. That figure was already known. The bigger development is what investigators now say happened before the theft: attackers compromised third-party security products and used that trusted infrastructure as part of the path into Bitget's wallet environment.

Bitget says investigations by Mandiant, part of Google Cloud, and blockchain-security firm SlowMist found that compromised third-party security products ultimately enabled unauthorized access to systems involved in the exchange's wallet operations. SlowMist's investigation traces malicious activity back to Aug. 31, weeks before the Sept. 24 theft, while Mandiant's preliminary forensic findings describe lateral movement from compromised security appliances into a production wallet job server. (Bitget)

That changes how the incident should be understood. The public story is no longer simply a case of attackers getting into a crypto wallet and moving funds. Based on the evidence released so far, the intrusion involved trusted infrastructure, privileged internal access and manipulation of the withdrawal process so unauthorized transactions could move through parts of Bitget's normal operational workflow. (Bitget)

What happened to Bitget?

On Sept. 24, 2026, Bitget detected unauthorized transfers from part of its hot- and warm-wallet infrastructure. The exchange initially estimated the affected amount at $351.6 million, then revised the figure to $387.5 million after accounting for additional assets on Zcash and TRON. Bitget's current incident page rounds the loss to roughly $388 million. (Bitget)

The incident did not affect Bitget's cold-wallet holdings, according to the exchange. Bitget also says private keys were not compromised and customer account balances were not reduced. Those are statements from Bitget, rather than findings independently audited and published in full by an outside financial assessor, so they should be understood as the company's current position. (Bitget)

The exchange suspended withdrawals while it investigated the incident and carried out additional security checks. Deposits and trading continued, while withdrawals were restored in stages. BTC withdrawals resumed on Sept. 28, ETH withdrawals on Sept. 29, and USDT withdrawals on Ethereum, BSC, Solana and Tron were opened on Sept. 30. Bitget's published schedule says remaining token withdrawals, fiat withdrawals and P2P services were scheduled for Oct. 2, subject to the security validation process. (Bitget)

For users, that recovery schedule is more useful than the headline loss alone. An exchange incident isn't fully resolved simply because the attacker has stopped moving funds. Users also need to know when withdrawals return, whether the relevant systems have been rebuilt and whether the company can explain how the original access path was closed.

The attack started before the theft

One of the most significant findings from the investigation is that the intrusion appears to have begun weeks before the theft became visible on the blockchain.

SlowMist says the earliest malicious activity it identified dates to Aug. 31. The activity involved a third-party security product identified in the public report as "Product A." According to SlowMist, a service running on one of Product A's nodes was exploited through a zero-day vulnerability. The attacker then executed a hidden script, accessed an environment variable containing a database password and connected to the product's database. Similar activity was later found on other nodes. (Cointelegraph)

A zero-day is a vulnerability that is being exploited before defenders have had an opportunity to deploy a fix. Here, the important point isn't simply that a zero-day was involved. It's the timeline.

The earliest activity identified by SlowMist predates the Sept. 24 theft by more than three weeks. That suggests the visible loss event was the final stage of a longer intrusion rather than the moment the attack began. SlowMist says its investigation into how the attacker moved between the affected systems is still ongoing. (Cointelegraph)

For defenders, that distinction matters. If an organization looks only for the transaction that caused the financial loss, it can miss the earlier compromise that gave an attacker the access needed to create that transaction in the first place.

Two security products became part of the attack path

Mandiant's preliminary findings add another layer to the picture.

According to the report, on Sept. 24 the attacker gained unauthorized privileged access to two Bitget third-party security appliances, identified as appliances A and B. Mandiant found a web shell on appliance B along with a command-and-control connection. From that persistent access, the attacker moved laterally to Bitget's production wallet job server and deployed malicious packages. Mandiant explicitly describes its findings as preliminary, meaning the investigation was still underway when that report was issued. (Mandiant / Google Cloud Security)

SlowMist describes activity involving the same two third-party products, anonymized as Product A and Product B, together with a wallet application host. On Product B, the attacker gained access to the management platform using an internal employee identity and attempted to inject commands, change configurations and upload malicious files. (Cointelegraph)

The public reports do not identify the vendors or products by name. They also don't establish every step between the first Product A compromise, the later Product B compromise and the final wallet intrusion.

So the broad route is clearer, but the complete chain of lateral movement is not yet public.

That's an important distinction. Security teams can act on the evidence that a trusted management layer was compromised, but the most useful forensic questions—how credentials moved, which controls failed to stop the movement and exactly how the attacker reached the wallet system—may depend on further investigation.

How the attackers actually moved the money

The evidence released so far suggests that the attackers did not simply obtain Bitget's private keys and transfer funds directly.

Bitget says the attackers obtained high-privilege internal credentials and used them to inject forged withdrawal commands into the wallet system. The exchange says those commands caused abnormal transfers to pass through parts of its existing workflow and bypass risk verification. Mandiant separately says the attacker reached the production wallet job server and deployed malicious packages there. (Bitget)

SlowMist found another important piece of evidence: a deleted, highly customized withdrawal tool recovered during its investigation. According to the investigation, that tool could forge risk-control parameters, construct withdrawal requests and invoke the withdrawal process. (Cointelegraph)

That makes the phrase "wallet hack" a little too simple.

A crypto exchange doesn't necessarily need to lose its private keys for its security model to fail. An attacker who gains enough privileged access to the software and services surrounding the signing process may be able to make legitimate infrastructure carry out an illegitimate operation.

That appears to be the central technical lesson from the Bitget incident. The attackers were allegedly abusing trusted access around the wallet process rather than relying on a straightforward theft of private keys.

Imagine a bank where the vault itself remains locked, but an attacker gets administrator access to the system that prepares and authorizes transfers. The physical vault hasn't been broken open, yet the workflow around it has been compromised. The analogy isn't perfect, but it captures the security problem: protecting the final asset isn't enough if too much authority sits in the systems that control how that asset is moved.

The theft unfolded over hours, not seconds

SlowMist's on-chain analysis places the earliest verified transfer at 2:31 a.m. on Sept. 25 in UTC+8, followed seconds later by another transfer on Ethereum. The transaction activity continued across multiple blockchains for roughly two hours and 52 minutes, according to the investigation. (Cointelegraph)

Bitget's own incident timeline records its detection of unauthorized transfers at 18:31 UTC on Sept. 24. The exchange says its reconciliation system identified a major discrepancy at 19:05 UTC, after which Bitget activated its highest-level emergency response and later shut down withdrawal-related signing services. (Bitget)

The timeline also shows why responding to this kind of incident is more complicated than simply blocking an attacker.

Once suspicious withdrawals are detected, the exchange has to determine whether the transactions came from a compromised component, whether other systems were also affected and which wallet functions can safely remain online. Turning everything back on immediately can create another risk if the original privileged access hasn't been fully removed.

That helps explain the staged restoration of withdrawals. Re-enabling a wallet workflow after a privileged infrastructure compromise is different from restarting an ordinary service after an outage. The exchange has to establish that the systems generating those transactions can be trusted again.

Why compromising security software is such a serious problem

There is a broader security lesson here that reaches well beyond cryptocurrency exchanges.

Security products are trusted and often highly privileged by design. They may monitor traffic, manage infrastructure, enforce policy, administer access or sit close to sensitive systems. A compromise inside that layer can therefore give an attacker a route to systems that would otherwise be difficult to reach.

Mandiant's findings illustrate that risk directly: the attacker allegedly used compromised security appliances as the route to a production wallet job server. (Mandiant / Google Cloud Security)

That doesn't mean security software is inherently less trustworthy than other enterprise software. It means organizations need to separate two ideas that are often treated as the same: trusted and unreachable.

A product can be trusted while still being a potential entry point.

For companies handling large amounts of money, credentials or other high-value data, the practical response is architectural. Sensitive environments benefit from tighter privilege boundaries, stronger separation between management planes, close monitoring of administrative identities and independent checks around unusually sensitive actions.

The point isn't to assume every security appliance will be compromised. The point is to design the environment so that one compromised security product doesn't automatically become a bridge into the most valuable system behind it.

The Bitget case makes that distinction unusually concrete.

What this means for Bitget users

For users, the immediate question is whether they can access their funds and normal exchange functions.

Bitget has been restoring withdrawals in stages. The exchange says BTC and ETH withdrawals resumed as scheduled, while USDT withdrawals opened on Sept. 30 across Ethereum, BSC, Solana and Tron. Bitget's current public schedule places remaining supported tokens, fiat withdrawals and P2P services on Oct. 2, subject to security validation. (Bitget)

Bitget also says the theft came from hot- and warm-wallet infrastructure rather than user account balances, and that its Protection Fund holds more than $464 million. Those are company statements about its own systems and resources; they shouldn't be read as an independent audit of Bitget's complete financial position. (Bitget)

For someone using Bitget during the restoration period, the practical issue is simple: don't treat a message, email or social-media post as proof that a withdrawal problem has been fixed. Use the exchange's official support and status information rather than a link supplied by someone claiming to be helping.

There's also a second risk that often appears after a high-profile crypto incident: impersonation and recovery scams.

Bitget has warned users not to share passwords, private keys, seed phrases or verification codes with anyone claiming to help recover assets or restore withdrawals. (Bitget)

That warning matters because a major security incident creates exactly the conditions scammers look for: users are worried, normal services may be temporarily unavailable and people are actively searching for updates. An unsolicited "recovery" offer can sound convincing precisely because it arrives when the user is already looking for answers.

What about the suspected attacker?

Attribution remains separate from the technical investigation.

Bitget CEO Gracy Chen has previously pointed to indicators she believes resemble infrastructure associated with North Korean hacking groups, and independent reports have discussed the same possibility. The Mandiant and SlowMist material cited here, however, does not establish a final public attribution to North Korea. (Tom's Hardware)

That distinction is worth keeping clear.

Forensic evidence can be strong when it shows which systems were compromised, what malware or commands were used and how transactions were generated. Attribution is harder. Similar infrastructure can be reused, copied or deliberately exposed to mislead investigators, and the public evidence available so far doesn't provide enough information to treat the actor's identity as settled.

The technical attack path is therefore a stronger conclusion than the identity of the attacker.

The recovery problem is harder than the intrusion problem

Stopping the intrusion is only one part of the response. Recovering the stolen cryptocurrency is another.

Bitget has created a recovery bounty program and says it is working with security companies and other platforms to trace and freeze assets. Some funds linked to the incident have been frozen by external services, but the amount publicly documented as frozen remains far below the total value involved. The exact figure can change as investigators continue tracing transactions across chains. (Bitget)

Cryptocurrency has an unusual property in these situations: transactions are publicly visible on supported blockchains, which gives investigators a detailed trail to follow. But visibility isn't the same as recoverability.

Once stolen assets are swapped between tokens, moved across networks or sent through services with different controls, following them can become more difficult. Even when investigators can identify where the funds went, freezing or recovering those assets depends on what happens at the receiving service and whether the assets can still be intercepted.

So a strong forensic investigation doesn't automatically produce an equally strong financial recovery.

For Bitget, those two tracks will continue in parallel: determining exactly how the breach happened and determining how much of the stolen value can actually be recovered.

What the new findings really change

Before the latest independent reports, the central explanation was that attackers had breached a backend component of Bitget's wallet infrastructure and manipulated the withdrawal process.

The new evidence pushes the starting point further back.

The current findings indicate that attackers compromised trusted third-party security infrastructure, maintained access, moved laterally toward the production wallet environment and used tooling capable of manipulating the withdrawal process. SlowMist's discovery of malicious activity dating to Aug. 31 also suggests that the exchange was dealing with a longer-running intrusion than the Sept. 24 theft alone would indicate. (Mandiant / Google Cloud Security)

That's the part of the story worth watching.

The $387.5 million figure shows the scale of the incident. The attack path explains why the incident was possible.

It also exposes a broader weakness that can affect any organization with highly privileged third-party software: an attacker may not need to break through the final security boundary if they can first compromise something that is already trusted on the inside.

For Bitget, the next milestones are straightforward but significant: complete withdrawal restoration, continue tracing the stolen assets, publish more forensic findings and show how the new controls prevent the same trust path from being abused again.

The biggest unresolved question isn't whether Bitget was hacked. It is how much of the chain between the original third-party compromise and the final wallet manipulation can be reconstructed, and whether the exchange's revised architecture leaves the attacker with any comparable route back in.