Bitget has released the findings from security firm SlowMist's investigation into the September 24 breach that saw more than $350 million drained from the exchange. In a post published on September 30, 2026, the company said the probe identified malicious activity involving third-party security products, including a zero-day vulnerability, and recovered a customized tool the attacker used to initiate unauthorized withdrawals.
The root cause points outside Bitget's own code
The headline detail is where the weakness sat. Rather than a flaw in Bitget's core systems, SlowMist attributed the entry point to a zero-day vulnerability in a third-party security product. A zero-day is a defect the vendor had no prior knowledge of and no patch for at the time of exploitation, which leaves the customer running it exposed until the flaw is found.
SlowMist also recovered a customized tool built to push through unauthorized withdrawals once access was gained. That is the difference between a probe and a targeted operation: the attacker was not improvising with off-the-shelf scripts but running purpose-made software against Bitget's withdrawal flow.
Bitget said the findings align with the attack path it had previously described, and add further detail on how the incident unfolded. In other words, this is confirmation and expansion of the earlier account rather than a revision of it.
The picture that has filled in since September 24
The breach was one of the larger exchange losses reported this year. In the days after, the story moved fast. Bitget restarted BTC withdrawals as part of a phased resumption, a signal that the exchange judged its systems safe enough to reopen access under controls. On the recovery side, blockchain investigators traced how North Korea-linked actors routed a slice of the stolen funds through Chainflip and CoW to launder the proceeds.
The SlowMist findings close part of the loop by naming the mechanism. What remains open, based on the post available here, is the identity of the specific third-party product involved and whether other operators running the same software carry the same exposure. Bitget did not name the vendor in the post.
The read for Bitget cardholders
The Bitget Card funds from balances held inside the Bitget account, so an exchange-side breach is not an abstract event for a cardholder. The money that backs card spending sits on the same platform that was attacked. When withdrawals paused during the response, access to those funds paused with them.
There is a second-order point in the root cause that matters here. The failure came through a trusted security vendor, not through user error or a phishing lure. A cardholder practicing perfect personal security still could not have prevented this, because the weak link was upstream in the exchange's own supply chain. That is the defining feature of custodial risk: the safety of the funds depends on the operator's defenses, including the defenses of the third parties it relies on.
The alternative design is worth stating plainly. Cards that spend from your own wallet keep the private keys with the user, which removes the exchange as a single point of failure on the funding side. That trade is not free, since self-custody moves the burden of key security onto the individual, but it takes an incident like this one off the table for the money backing the card.
For current Bitget users, the practical steps are unchanged: keep two-factor authentication on, treat any unexpected withdrawal prompt as hostile, and hold on the card only what is needed for near-term spending rather than parking a large balance on the venue.
Overview
Bitget published SlowMist's investigation into its September 24 breach, attributing the more than $350 million loss to a zero-day vulnerability in a third-party security product and a custom tool the attacker used to force unauthorized withdrawals. The findings confirm and extend Bitget's earlier account. For cardholders, the takeaway is that the funding balance behind a Bitget Card sits on the same exchange that was hit, and the weak point was a trusted vendor rather than the user, which is the core case for keeping only near-term spending funds on any centralized platform.
