If a major exchange’s cold wallets were not compromised and its private keys were not exposed, how could hundreds of millions of dollars still leave the platform? This incident exposes more than a software vulnerability: it reveals the fragility of an entire trust chain in digital asset custody.
Article contents · 10 sections
01 · Not market volatility, but an intrusion into the exchange’s backend02 · From two small tests to an outflow across blockchains03 · Why can assets be transferred without stealing private keys?04 · Suspending withdrawals, isolating systems, investigating and restoring service in stages05 · An account balance does not mean direct control of on-chain assets06 · Look beyond advertising claims of “security” and “100% reserves”07 · Reduce the cost of a single point of failure instead of seeking “absolute safety”08 · Control risk first, then preserve evidence09 · The greatest risks often lie in components trusted by default10 · What else to know about the US$388 million theftNot market volatility, but an intrusion into the exchange’s backend
On September 24, 2026, unauthorized on-chain transfers occurred from some of Bitget’s hot and warm wallets. The initial announcement put the affected amount at approximately US$351.6 million. After recalculating transfers across networks and assets, the platform revised the final figure to approximately US$388 million. The two figures are estimates of the same incident at different investigation stages, not two separate thefts.
This incident deserves the attention of all cryptoasset holders not only because of its scale. The attackers reportedly did not need to steal cold-wallet private keys: they entered internal systems through a third-party security product used by the exchange and used stolen privileged credentials to forge withdrawal instructions. Transfers that appeared to follow normal business procedures were no longer genuinely authorized by users.
A distinction is essential: assets leaving an exchange wallet do not mean that every user’s account balance was directly reduced. Bitget stated that users’ recorded balances were unaffected and that its protection fund would cover the loss. Whether those commitments are fulfilled, assets remain promptly withdrawable and remediation proves effective are questions users should continue to examine.
From two small tests to an outflow across blockchains
On September 24, the attackers first made two small test transfers: 0.184 ETH from an Ethereum hot wallet and 193 TRX from a TRON hot wallet. According to explanations given by Bitget management in an interview with The Block, both transfers were below the risk-monitoring alert thresholds in place at the time.
About half an hour later, the attackers began larger transfers. The platform’s review described activity across Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism and Avalanche, with funds rapidly converging on attacker-controlled addresses.
On September 24, the platform activated emergency measures after its reconciliation system detected unusual discrepancies and suspended user-initiated withdrawals. Restricting ordinary user withdrawals does not necessarily mean that every compromised backend transfer path has immediately been blocked.
The security team then isolated relevant systems, examined internal privileges and third-party components, and worked with blockchain security firms to trace funds. As more on-chain transfers were classified, the platform raised the affected amount from approximately US$351.6 million to approximately US$387.5 million.
Bitget began restoring withdrawals in stages on September 28, restored USDT-related withdrawals on September 30 and completed its announced phased restoration plan on October 2. It also reported progress on vulnerability fixes, fund tracing and replenishing the protection fund.
Why can assets be transferred without stealing private keys?
Layer one: an entry point in the third-party supply chain. Large exchanges deploy numerous external security tools, logging components, monitoring systems and management tools. A zero-day vulnerability in a product with elevated access could allow attackers into a protected internal environment. The root cause disclosed by Bitget pointed to a third-party security product.
Layer two: misuse of valid credentials. Once attackers obtain privileged internal credentials, the system may see an authorized account accessing the backend rather than an obvious intruder. Successful authentication proves only that credentials were accepted, not that the operator is their legitimate holder.
Layer three: forged business instructions. According to the platform, attackers injected fraudulent withdrawal commands directly into the wallet backend, placing them on an execution path ahead of some validation steps. The problem was not a blockchain moving coins by itself, but failures in instruction authenticity, the authorization chain and the separation of risk controls.
Layer four: removing traces after transfers. Public reviews stated that attackers deleted some records associated with forged instructions, requiring broader examination of logs, systems and credentials. Deleting operational traces does not erase on-chain transactions: asset movements may still be traced, but identifying an address does not guarantee recovery.
This is not a technical manual for reproducing the attack. The relevant defensive principle is that third-party tools, identity privileges, business approvals, signing systems and anomaly monitoring must not depend on a single trust chain that can be bypassed.
Suspending withdrawals, isolating systems, investigating and restoring service in stages
After detecting anomalies, Bitget suspended withdrawals, isolated affected systems and contacted blockchain analysis firms and relevant organizations to trace assets. Suspensions inconvenience ordinary users, but reopening withdrawals before confirming that the entry point is closed may increase risk.
The platform publicly stated that it had reset internal credentials, tightened highly sensitive privileges, disabled or repaired affected third-party functionality and strengthened independent withdrawal verification. On September 30, it said independent investigations by Mandiant and SlowMist broadly agreed with its disclosed principal attack path. Readers should examine the original reports and the scope of disclosure rather than relying solely on headlines.
Withdrawals resumed in stages: BTC on September 28, ETH and some EVM networks on September 29, USDT on September 30, and other supported cryptocurrencies, fiat and P2P-related withdrawals on October 2. The precise networks and assets covered should be checked against the official announcements issued at the time.
The platform stated that account balances remained accurate and the protection fund would cover the loss. It also disclosed measures including replenishing that fund and updating proof of reserves. Proof of reserves, protection fund size and unchanged account balances are different safety indicators; none alone replaces scrutiny of liabilities, custody arrangements and ongoing solvency.
An account balance does not mean direct control of on-chain assets
Centralized exchanges offer convenience through custody: users can trade and transfer funds after logging in without handling private keys for every transaction. In return, they generally depend on the exchange to hold the corresponding on-chain assets and manage withdrawals, risk controls and accounts.
There are at least five risk categories: compromises of hot or warm wallets; abuse of internal privileges, vendors or business systems; liquidity and solvency risk; account-level phishing, SIM swapping and email compromise; and withdrawal suspensions or regulatory restrictions in extreme circumstances.
Cold wallets reduce the risk of exposing keys online, but do not make an entire exchange immune to attack. The path disclosed by Bitget illustrates that other asset pools and business authorization processes may be attacked even when cold wallets remain unaffected.
Nor is it valid to claim that self-custody is absolutely safe. Exposed recovery phrases, tampered devices, malicious transactions signed by users or failed recovery processes can also cause losses. Exchange custody and self-custody allocate risks in different ways.
Look beyond advertising claims of “security” and “100% reserves”
First, examine public disclosure. Are the incident date, affected scope, changes in loss estimates, root cause and remediation disclosed promptly? Are verifiable on-chain addresses, audit explanations or independent reports available?
Second, examine fund segregation. Are there clear limits and approval procedures for hot, warm and cold wallets? Are critical privileges minimized? Do high-risk withdrawals require verification independent of business systems?
Third, examine solvency. Proof of reserves shows the relationship between assets and defined liabilities at one point in time. Check whether all relevant liabilities are covered and whether borrowing or pledging arrangements impose restrictions.
Fourth, examine incident response. How quickly is exposure limited after anomalies are detected? Is there a public withdrawal restoration plan, a communication channel for affected users, and an explanation of compensation grounds and implementation progress?
Fifth, examine user protections. Are hardware security keys, withdrawal address allowlists, login notifications, device management, anti-phishing codes and account-freezing mechanisms supported? Security is a set of testable capabilities, not a single label.
Reduce the cost of a single point of failure instead of seeking “absolute safety”
01 | Diversify custody. Separate everyday trading funds from long-term holdings and avoid concentrating all assets in one exchange or wallet indefinitely. Diversification also has management costs; do not use unfamiliar platforms merely to spread funds around.
02 | Protect account access. Prefer unique strong passwords, a password manager and supported security keys or authenticator apps. Avoid relying on SMS codes as the only protection. Regularly review logged-in devices and API keys.
03 | Enable withdrawal protection. Configure address allowlists, cooling-off periods for address changes, login alerts and anti-phishing codes. Do not casually grant remote-control access to strangers. Feature availability and effectiveness vary by platform.
04 | Check every authorization. On-chain transfers, token approvals and message signatures are different actions. Do not sign unfamiliar websites’ requests to claim an airdrop, verify assets or unfreeze an account without understanding what you are signing.
05 | Store recovery phrases correctly. Do not take screenshots, sync them to the cloud, send them to support or paste them into webpages. Backups should be secure, offline and recoverable, accounting for practical issues such as fire, loss and inheritance.
06 | Keep devices updated. Use supported iOS and browser versions and install security updates promptly. Do not panic over exaggerated claims that simply opening a webpage always leads to theft. Attacks have different prerequisites; browsing alone does not mean wallet private keys have been exposed.
07 | Use small tests and regular recovery drills. Confirm a new recipient address with a small initial transfer. For long-term self-custodied assets, periodically verify backup and recovery procedures without entering recovery phrases on untrusted devices or websites.
Control risk first, then preserve evidence
If an exchange account shows unfamiliar logins, withdrawal notices or API activity, immediately check it through an official entry point you previously saved. Change the password, revoke suspicious API keys, sign out unknown devices, enable or update multifactor authentication and contact official platform security support.
If a self-custody wallet has unauthorized on-chain transfers, use a secure device to assess whether remaining assets should move to a newly generated wallet. If only a token approval was abused, consider revoking it after verifying the network and contract. Do not trust unsolicited messages claiming stolen coins can be recovered for a fee.
Preserve transaction hashes, blockchain names, times, relevant addresses, account security emails and screenshots. Give the platform or law enforcement verifiable information when reporting; never give anyone your recovery phrase, private key or verification code.
Once assets pass through mixers, bridges or multiple layers of addresses, tracing and recovery may be difficult. Finding the fund flow does not guarantee freezing or restitution. After a loss, beware of a second round of “asset recovery” scams.
The greatest risks often lie in components trusted by default
Based on public information, the main concern in the Bitget incident is not the supposed brilliance of hackers. Security products can themselves become entry points, attackers can misuse legitimate credentials, and ordinary business workflows can execute instructions without genuine authorization.
For exchanges, security involves more than protecting private keys. It also requires vendor risk management, credential lifecycle management, privilege separation, independent withdrawal checks, real-time monitoring of unusual fund flows, tamper-resistant audit logs and emergency drills.
For users, the key is not finding a platform that will never have an incident, but planning ahead: would a three-day withdrawal suspension seriously disrupt my life and finances? If my phone or email account were compromised, would I have an independent recovery method? If I lost a wallet, could I restore it safely?
Asset tracing, recovery and long-term remediation in this incident require continued attention. Professional security assessments should change with evidence rather than emotional reactions.
What else to know about the US$388 million theft
Q: Did every Bitget user directly lose assets? A: The platform said users’ recorded balances were unaffected and its protection fund would cover the loss. This is the platform’s public commitment and should not be described as direct theft from every user’s wallet.
Q: Why did US$351.6 million become US$388 million? A: According to the platform’s update, the latter is the final affected amount after recalculating transfers associated with the same incident, not a second attack.
Q: Were cold wallets compromised? A: According to Bitget and the investigative findings it disclosed, some hot and warm wallets were affected, cold wallets were not, and no private-key exposure was found.
Q: Why were there still transfers after anomalies were detected? A: Risk controls, reconciliation, signing and internal instruction paths are not identical. Suspending user withdrawals does not necessarily cut off every internal path immediately. Formal forensic material should determine the details.
Q: What should users do now? A: Verify account status through official channels, strengthen authentication, review withdrawal addresses and API keys, consider a reasonable allocation of custody for long-term funds, and beware of compensation or recovery scams impersonating the platform.