At 18:31 UTC on 24 September 2026, Bitget’s reconciliation system flagged a discrepancy between what its hot and warm wallets should have held and what they actually held. Thirty-four minutes later, the exchange’s own risk controls auto-blocked further withdrawals. By then, attackers had already moved $387.5 million in cryptocurrency off the platform across 12 wallet addresses and 11 blockchains. The breach didn’t start with a stolen private key or a phished employee. It started a month earlier, inside a security product Bitget had installed to protect itself.
The attack didn’t touch Bitget’s own code
Bitget’s own account of the incident, published as its security incident timeline, describes the root cause in deliberately hedged terms: an attacker “may have exploited a vulnerability in a third-party security product to potentially obtain high-level internal credentials,” then used those credentials to send fraudulent withdrawal commands that bypassed Bitget’s existing authorization checks. The exchange has not named the vendor or published a CVE.
Independent forensic reporting fills in more of the chain. According to BleepingComputer’s reporting, drawing on investigations by blockchain security firm SlowMist and Google-owned Mandiant, two separate third-party security appliances were involved — referred to in the forensic writeups only as “Product A” and “Product B.” The earliest malicious activity traces to 31 August 2026, when a zero-day in Product A let an attacker run a hidden script under a legitimate service process, read an environment variable containing a database password, and connect to that database directly. Over the following weeks, SlowMist identified the same pattern recurring on two more Product A nodes. On 24 September, the attacker escalated: privileged access to both appliances, a web shell planted on Product B, and a command-and-control channel back to attacker infrastructure. From there, Mandiant’s account says the attacker moved laterally to Bitget’s production wallet job server and deployed a custom tool built specifically to match that server’s withdrawal logic. The theft itself — the actual transfers — ran for roughly three hours early on 25 September, Hong Kong time, before Bitget’s reconciliation system caught the discrepancy.
Why a security appliance is a better target than a wallet
Hot and warm wallets exist because an exchange has to let some funds move automatically — user withdrawals, market-making, rebalancing — without a human clicking approve on every transaction. That automation runs through an authorization layer, and the authorization layer has to trust something: often a database holding signing credentials, or a security appliance that vouches for which requests are legitimate. An attacker who compromises that trusted layer doesn’t need to break the wallet’s cryptography at all. They just need the automated pipeline to believe a fraudulent withdrawal request is a routine one — exactly what Mandiant describes the custom tool doing, tailored to Bitget’s own withdrawal logic well enough to walk past the risk controls that would normally catch an anomalous transfer.
This is the same structural lesson as Citrix NetScaler’s zero-days running unnoticed for weeks earlier this year: the products deployed specifically to secure an environment are themselves high-value targets, precisely because compromising one buys an attacker the trust that product was supposed to gatekeep. A firewall, a secrets manager, a security appliance — each is a single point where a breach doesn’t just expose data, it inherits the authority the product was trusted to enforce.
What the numbers don’t quite agree on
Bitget’s own incident page states the loss as approximately $388 million across 12 wallet addresses, 13 asset types and 11 blockchains — Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand and Celestia. Press reporting, including The Hacker News’s coverage, cites $387.5 million, a figure Bitget itself revised upward slightly after reclassifying additional Zcash and TRON transactions. The discrepancy is minor and explainable. More notable is a different kind of gap: CEO Gracy Chen was reported attributing the attack to North Korean state hackers based on IP behavior patterns and on-chain wallet-overlap analysis, while Bitget’s own published incident account states plainly that the company “will not speculate on attribution without verified investigative findings.” Both statements came from the same organization. They don’t describe the same level of confidence.
Bitget says cold wallets were never touched — the breach was confined to the hot and warm wallet infrastructure that has to stay connected to move funds automatically — and that its separate self-custody Bitget Wallet product was unaffected. The exchange has since revoked and reissued the credentials the attacker obtained, disabled the compromised third-party functionality, rebuilt its withdrawal verification pipeline, and pointed to a User Protection Fund holding more than $464 million to cover affected customers. Roughly $1.1 million of the stolen funds has been frozen by Circle, Tether and NEAR Intents — a small fraction of the total, underscoring how little of a crypto theft is typically recoverable once funds clear the first hop off an exchange.
The lessons that generalise
A security product’s own compromise doesn’t look like a typical breach — it looks like the system working correctly. When a web shell on a security appliance can inject authorization for fraudulent transfers, every downstream system that trusts that appliance’s verdict has no way to tell the difference between a real approval and a forged one. The defense has to live in redundant, independent verification — not in trusting the gatekeeper more tightly.
Automated financial pipelines move faster than most detection systems. Bitget’s reconciliation system caught the discrepancy within roughly 35 minutes of the first fraudulent transfer and auto-blocked further withdrawals — a genuinely fast response. It still wasn’t fast enough to stop $387 million from moving in a three-hour window, because the attacker’s tool was purpose-built to operate inside Bitget’s own withdrawal logic at machine speed.
Architectural segmentation bounded the damage more than incident response did. Cold wallets being structurally incapable of automated withdrawal is why the loss was capped at the hot and warm tier rather than Bitget’s entire treasury. That’s a design decision made long before this attack, not a consequence of how quickly anyone responded to it.
A company’s most confident public statement and its most careful one are not always the same statement. An unnamed CEO quote attributing a breach to a nation-state actor carries different evidentiary weight than a published incident report that explicitly declines to speculate on attribution. Readers — and regulators — should weigh each for what it actually is: one is a claim, the other is a disclosed finding.
Tech-Bee is an independent technology publication. This piece is drawn from Bitget’s own published security incident account and reporting by BleepingComputer and The Hacker News, citing forensic findings from SlowMist and Mandiant.