The Bitget Breach and the Security Failures Behind Crypto’s 2026 Losses
At 18:31 UTC on September 24, Bitget’s security systems detected unauthorized transfers from some of its hot wallets. The exchange activated its emergency response and suspended withdrawals. Its first public notice appeared at 21:39 UTC. A later service update confirmed that withdrawals remained unavailable while deposits and trading continued.
Bitget initially estimated the affected assets at $351.6 million. On September 25, it raised the figure to $387.5 million after including Zcash and TRON assets in its accounting. The revision was not presented as evidence of a second attack. By September 29, its incident page rounded the loss to approximately $388 million across 12 hot and warm wallet addresses. The affected assets spanned several networks and included ETH, XRP, stablecoins, ZEC and TRX.
The exchange said its cold wallets were unaffected and customer account balances had not changed. It pointed to a protection fund holding 5,500 BTC, valued at more than $464 million when the update was published, to cover the financial impact. Those were Bitget’s statements about its capacity to absorb the loss, not conclusions from a completed independent audit.
For customers, the immediate test was whether they could withdraw. On September 26, Bitget announced a phased reopening: BTC on September 28, ETH on September 29, USDT on September 30, and other assets, fiat and peer-to-peer services on October 2. It later reported that BTC withdrawals had resumed and that 9,585 withdrawal requests, totaling about 4,098 BTC, had been processed by 09:00 UTC on September 28. The remaining dates were a schedule, not proof that every service had already returned.
Bitget’s public response addressed the issues circulating around the incident: the size of the loss, whether balances were intact, when withdrawals would resume, and whether its reserves could withstand the breach. It announced a recovery bounty and said Mandiant and SlowMist had joined the investigation. In a September 28 briefing, CEO Gracy Chen described an attack that began with a vulnerability in a third-party security product. According to Bitget, attackers obtained internal credentials and inserted forged withdrawal instructions into its wallet system, bypassing checks before ordinary withdrawal records were created. The company says private keys were not stolen. A fuller external forensic report has yet to establish that account independently.
Bitget’s Earlier Incidents Involved Different Risks
Bitget has faced serious operational incidents before, but describing all of them as previous hacks would obscure what failed in each case.
On October 7, 2024, its BGB token underwent a sharp price disruption lasting roughly six minutes. Bitget attributed the abnormal movement to several large leveraged transactions that set off forced liquidations across pledged lending, margin and futures positions. It promised to compensate eligible users whose positions were affected. This was a market-risk and liquidation-control episode, not a reported theft from an exchange wallet. The relevant safeguards were price monitoring, collateral rules and the ability to interrupt a liquidation cascade.
On April 20, 2025, Bitget reported abnormal trading in its VOXELUSDT perpetual futures contract between 08:00 and 08:30 UTC. The exchange said certain accounts might have engaged in market manipulation. It restricted those accounts, proposed rolling back irregular trades and offered a compensation process to users who lost money during the window. Again, the disclosed problem concerned trading controls and the fairness of executed transactions — not missing assets from custody.
The September 2026 breach reached a different system: the infrastructure authorized to move assets off the platform. If Bitget’s account is borne out, the attacker did not need a private key. Access to a sufficiently privileged internal system allowed forged instructions to be treated as legitimate withdrawals. That distinction matters because a cold-wallet policy can limit the amount exposed while leaving the hot-wallet approval process vulnerable.
The three episodes therefore should not be counted as three versions of the same failure. They do show how much an exchange’s promise of “security” encompasses: orderly markets, accurate account records, withdrawal controls and custody. Compensation after a liquidation cascade, a trade rollback and a protection fund after a wallet breach are different remedies. Each addresses losses after a different control has failed.
Bitget’s fund also raises a question that its earlier compensation promises did not. A reserve of more than $464 million exceeds a loss of approximately $388 million, but the margin is tied to the market value of its BTC holdings. Its published 127% proof-of-reserves ratio is another measure: it concerns assets relative to customer liabilities at a reporting point. Neither figure, on its own, explains how an attacker reached the wallet system, how much has been recovered or what controls now prevent the same instructions from being accepted again.
Beyond Bitget: The Major Attacks of 2026
The wider industry has experienced both more frequent small attacks and a few exceptionally large ones. TRM Labs counted 207 hacks and $972 million stolen in the first half of 2026, compared with 83 incidents in the first half of 2025. The median loss was about $219,000, while the mean was $4.7 million. That gap shows how strongly a handful of major incidents shaped the total.
TRM classified 125 of the 207 incidents as smart-contract exploits. Yet infrastructure and operational compromises — about 15% of incidents — accounted for roughly 76% of the money stolen. This is one firm’s dataset and classification, not a complete ledger of every loss in 2026. Its contrast between incident count and value is nevertheless useful: the most common weakness was not necessarily the costliest one.
Get @Xmultiverse_org’s stories in your inbox
Join Medium for free to get updates from this writer.
On April 1, attackers drained approximately $285 million from Solana-based trading protocol Drift in around 12 minutes. TRM’s reconstruction describes weeks of preparation. Attackers allegedly induced members of Drift’s security council to pre-sign transactions using Solana’s durable-nonce feature, which allows a transaction to be executed later. A migration to a new multisignature configuration with no timelock removed a delay during which suspicious administrative changes might have been stopped.
The attackers also created a token, CarbonVote, seeded it with limited liquidity and generated trading activity that made its price appear credible. After gaining administrative control, they enabled the token as collateral, raised withdrawal limits and extracted real assets against its manufactured value. The attack crossed several boundaries: signer judgment, governance authority, oracle pricing and withdrawal limits. An audit of the trading contract alone could not have secured all four.
On April 18, KelpDAO lost approximately $292 million in rsETH through a cross-chain bridge. Chainalysis reported that attackers compromised internal RPC nodes used by a verifier and disrupted an external node with a denial-of-service attack. The verifier then accepted a false account of tokens being burned on the source chain. A destination-chain contract released 116,500 rsETH even though the corresponding burn had not occurred. The on-chain release followed the contract’s rules; the information supplied to that contract was false.
KelpDAO’s bridge was configured to rely on one verifier for that message. The incident was therefore not a conventional smart-contract coding flaw. It was a failure in the machinery that told a contract what had happened elsewhere. KelpDAO paused the relevant contracts, blocking a reported second attempt involving roughly $95 million more in rsETH. The Arbitrum Security Council later froze 30,766 ETH associated with downstream movements of the stolen funds. Those actions limited further damage but did not erase the initial release of unbacked assets.
A different mechanism surfaced in September at Liquid Network, the Bitcoin sidechain. According to Chainalysis’s analysis, actors who described themselves as white-hat hackers exploited a transaction-validation cache flaw to create L-BTC without depositing the BTC that should back it. They then withdrew roughly 4,000 real BTC, worth about $320 million at the time, from the network’s reserve. After Blockstream patched the software, the actors returned 3,400 BTC. About 600 BTC remained under their control at the time of the September 9 report; neither their claimed motive nor the status of the remainder should be inferred from the partial return.
These cases should not be added into a single “losses this year” figure without accounting for different dates, recoveries and data providers. Their value as comparisons is more specific. Drift’s weak point involved people approving powerful transactions and the market data accepted as collateral. KelpDAO’s involved an off-chain source of truth for a bridge. Liquid’s involved validation software that treated new, invalid data as if it had already passed a check. Bitget says its own weak point was a third-party security product and the internal authority subsequently obtained. None is adequately described by the catch-all phrase “a blockchain was hacked.”
The Controls Behind the Losses
The first lesson is that control over an asset is broader than possession of its private key. In Bitget’s account, forged backend instructions caused a wallet system to execute transfers while the keys themselves remained protected. At Drift, pre-signed administrative transactions gave attackers an avenue to change what the protocol would accept. Security reviews must therefore map every route by which a transfer can be authorized, not simply identify where keys are stored.
That means treating privileged credentials, signer interfaces and approval workflows as part of custody. A large withdrawal should require independent checks on its destination, amount and underlying business record. Approval by a second person is weaker if both approvers see the same misleading interface or depend on the same compromised service. Timelocks and transaction simulations give defenders time and information to challenge a request before it becomes irreversible.
Second, a system needs independent ways to test the facts it acts upon. Drift accepted a price signal for thinly traded collateral that attackers had manufactured. KelpDAO’s destination contract accepted a verified message about a burn that never happened. Liquid’s affected nodes accepted an invalid proof because of a flawed cache check. In each case, the decisive error occurred before an otherwise valid-looking transfer. Price sources, cross-chain messages and cached verification results require checks against independent data and accounting constraints.
Third, containment has a measurable role. Cold wallets may reduce the assets available to an intruder in an exchange’s live environment. Withdrawal limits can slow an unauthorized drain. A bridge pause can prevent a second forged release. None of these measures proves the underlying system safe; each reduces what can be lost while an investigation begins. KelpDAO’s blocked follow-up attempt illustrates that a response can matter even when it comes too late to prevent the first transfer.
Finally, recovery claims need to be separated from security claims. A fund can compensate customers but cannot explain an intrusion. A proof-of-reserves snapshot can help assess assets against liabilities but cannot reconstruct an attacker’s permissions or validate every withdrawal. A frozen address is not the same as money returned to users. The strongest post-incident evidence is correspondingly varied: an independently reviewable technical account, reconciled liabilities and assets after the loss, documented compensation, and withdrawals functioning at meaningful volume.
What the Evidence Must Show After a Breach
Crypto’s 2026 incidents did not share one exploit. They reached the people, software and data that tell financial systems when to move value. The practical test after a breach is whether an operator can show where that authority failed, how the exposure was contained and — separately — how customers will be made whole.
The next evidence will come from operations, not reassurance. For Bitget, that means sustained withdrawal access across assets, a reconciled account of losses and recoveries, and an external report detailed enough to test its explanation of the attack. For the wider industry, it means examining who can approve transfers, which outside services those approvals depend on, and whether anyone can stop an apparently valid transaction built on false information. Protection funds remain important, but they measure an institution’s ability to absorb damage. They do not measure how difficult the next attack will be — or how quickly it will be detected.
