Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contracts

On September 24, 2026, approximately $387.5M was transferred from some of Bitget's operational wallets across Ethereum and other EVM networks, XRP Ledger, Zcash, and TRON. Bitget described the affected wallets as hot and warm wallets. The on-chain transactions carried valid wallet signatures. Bitget attributed the entry point to a vulnerability in a third-party security product and said private keys and cold wallets were not compromised [1, 2].

Based on public disclosures and on-chain evidence available as of September 29, 2026, 16:35 UTC, the first part summarizes the disclosed attack sequence, subsequent fund movements, service restoration, and the different responses of ecosystem participants. The second part combines those observations with our security experience to present a defense-in-depth framework for crypto institutions, together with practical security recommendations.

1. From Off-Chain Access to On-Chain Loss and Recovery

Bitget has attributed the entry point to a vulnerability in a third-party security product but has not disclosed the product, affected component, or technical exploit mechanism [1, 2]. Its public account describes the downstream path as internal access, forged withdrawal commands, bypassed risk verification, valid signatures, and on-chain transfers.

1.1 Attack Timeline and Attribution

The timeline reported by Bitget CEO Gracy Chen, together with on-chain records, shows how the incident developed [3]:

• 18:31 UTC, September 24: The first movements were 0.84 ETH and 93 TRX. Both were below the exchange's risk-control threshold.
• 18:58-20:09 UTC: Chen described seventeen larger transfers across Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism, and Avalanche, totaling approximately $361M [3]. On-chain records also show a 20.59M TRX transfer on TRON at 19:16 UTC.
• Seven minutes after the first large transfer: Bitget's reconciliation system detected a discrepancy and stopped user-initiated withdrawals. Bitget's timeline distinguishes that action from the later shutdown of wallet withdrawal and signing services at 21:44 UTC [1].

Chen said that the attacker deleted traces left by the fraudulent commands [3]. On preliminary attribution, she also said that the IP-address behavior and on-chain patterns were highly consistent with known North Korean hacking groups [4]. This remains a preliminary attribution rather than a final finding; Bitget's official incident page has not named a responsible group, and the investigation remains ongoing [1].

1.2 Fund Flow and Operational Recovery

On-chain records reflected in Bitget's official tracker show that stolen stablecoins were converted into ETH within minutes [5]. Unlike USDT or USDC, native assets such as ETH do not expose an issuer-controlled freeze function. This behavior is consistent with an attempt to reduce exposure to issuer-controlled freezes, but it does not establish the attacker's identity or level of experience.

The official affected amount later rose to approximately $387.5M as Bitget incorporated a more complete accounting that included Zcash and TRON [1]. Bitget published attacker addresses, a recovery-reporting portal, and an address API [1, 6], along with the real-time tracking site [5]. The site's holdings view reports the current distribution, while its fund-flow graph maps downstream addresses, services, bridges, and cross-chain routes.

At 16:35:28 UTC on September 29, the official tracker reported $322.67M in current attacker holdings, about $632,700 frozen across eight entries, $312,500 in issuer-freezable stablecoins, and $55.87M in transit or still under analysis [5]. The frozen total comprised $293,507 at NEAR Intents (which reported approximately $503,000 frozen during execution [12]), $239,242 frozen by Tether, and $99,990 frozen by Circle. Public sources do not reconcile the NEAR Intents figures.

At the same timestamp, the address explorer showed attributed-address balances concentrated in BTC ($288.51M), ZEC ($28.91M), and ETH ($7.17M) [5]. The explorer uses a different classification scope from the overview, so its $327.69M address-level total is not directly comparable to the overview's $322.67M current holdings figure.

Operational recovery also progressed. Bitget resumed ETH withdrawals at 08:00 UTC on September 29. By 09:00 UTC, it reported approximately 9,674 ETH in inflows and 9,023 ETH in outflows, so inflows exceeded outflows by roughly 651 ETH [7].

1.3 After the Funds Leave: Community Response

Once assets leave the affected institution's wallets, recovery depends on organizations outside the original security boundary. Bitget opened its tracing data and launched a bounty for eligible assistance that froze or recovered funds [1, 6]. Binance said its security team shared intelligence, tracked funds, and supported recovery [8]. Bybit CEO Ben Zhou offered assistance and updated the LazarusBounty recovery platform, noting that Bitget had helped Bybit after its own 2025 incident [9]. Bybit's response continued a pattern of mutual assistance between the two exchanges.

Infrastructure providers had different options because of their technical designs and governance models. Bitget asked THORChain to refuse service to publicly listed and actively tracked attacker addresses. Gracy Chen argued that "decentralization is a design principle, not a shield for facilitating known stolen funds" [10]. THORChain explained that it does not support selective blacklisting: its emergency controls can halt broader activity or a chain route, not one address or transaction. Some stolen assets continued moving from ETH into BTC through the network [11].

NEAR Intents reported a different response. Its SHIELD risk system identified and blocked more than $50M in attempted flows linked to the attackers after filtering duplicate attempts; approximately $503,000 was frozen during execution, while about $166,000 passed through. NEAR Intents also waived its share of Bitget's recovery bounty [12]. The $50M figure is attempted flow the system declined to process, not a frozen or recovered amount.

Large cross-chain recoveries usually require several participants. Exchanges can hold deposits or withdrawals, stablecoin issuers may freeze tokens, routing services may reject attributed flows where their design allows it, and base protocols may only be able to monitor and share indicators. Effective coordination starts with each participant stating what action it can take and what evidence it requires.

Intervention also creates risk. False attribution can block innocent users, while persistent blacklists can expand from incident-response tools into broader transaction-restriction mechanisms. A defensible response uses corroborated evidence, narrow and time-bounded restrictions, an appeal process, transparent action logs, and post-incident review. Where a system lacks selective controls, transparent capability disclosure helps set realistic expectations. Where discretion exists, published criteria and accountable decision-making can support consistent responses.

2. Breaking and Containing the Exploit Path: A Systematic Defense-in-Depth Security Framework

Drawing on the incident path and response documented in Section 1, together with our experience and expertise, we propose the two-layer framework below. For more on why code audits and monitoring do not cover the entire money-handling path, see Why Crypto Institutions Need Blockchain Penetration Testing [13].

• The disclosed exploit path runs from the third-party security product to on-chain transfers.
• The framework's prevention and detection layer contains the first three security practices. Sections 2.1 and 2.2 examine how privileged-access controls and independent intent verification can prevent an infrastructure foothold from progressing to signing. Section 2.3 covers asset-flow monitoring, which detects and escalates outbound anomalies and can hold risky inbound deposits.
• The response and recovery layer contains the fourth practice. It can be triggered by a high-confidence signal from anywhere in the prevention and detection layer, or by an operational fault. Section 2.4 covers the independent ability to pause affected operations or transfer exposed assets to verified safe destinations.

Each subsection follows the same structure: the security objective, the risk exposed by the incident path, and the preventive, detective, or response capabilities institutions can establish. These practices should rely on separate authority and evidence. Together, they reduce dependence on any single safeguard and give institutions prepared options for containing loss.

2.1 Privileged Access and Withdrawal Commands

The objective is to prevent a compromise of infrastructure or privileged systems from being sufficient to create a trusted withdrawal command.

A third-party product does not need direct signing access to affect asset movement. Access to credentials or systems that shape withdrawal commands may be enough to determine what another system signs. Such products belong to the institution-level Web3 attack surface [14]. Their risk depends on the value they can influence and the systems they can reach.

The required controls include least privilege, network segmentation, restricted update and administration paths, short-lived credentials, tamper-resistant logs, and a tested revocation procedure. Internal access must not automatically grant the ability to create a trusted withdrawal command. Every command should carry an authenticated origin, an immutable request identifier, and a signed or otherwise authenticated configuration version. Command creation, approval, signing, and broadcast should belong to separate privileges, and downstream systems should reject commands with unknown origins, stale configurations, or incomplete bindings.

2.2 Withdrawal Intent and Signing

The objective is to prevent a forged or manipulated withdrawal command from becoming a validly signed transaction.

A valid signature confirms that the corresponding private key signed the transaction data; it does not establish that the underlying withdrawal request was genuine or independently approved.

The signing boundary should reconstruct the expected transaction from an independent trusted record and compare every field that can move value. At minimum, approval should bind the chain, asset, amount, recipient, source wallet, transaction nonce, fee bounds, expiry, and original withdrawal or treasury request.

The component that constructs a withdrawal should not be the only source used to authorize it. Policy evaluation should consume independent account and risk data, while the signing system verifies that the final transaction data matches the approved intent. The active set of authorized signers, signing threshold, transaction nonce, and configuration must match the expected production state. Human reviewers need a normalized transaction view generated from the exact bytes to be signed, not a mutable summary supplied by the requesting backend.

2.3 Outbound and Inbound Asset Flows

The objective is to detect when actual asset movement diverges from independently reconstructed business intent.

A crypto institution can be both a source and a destination of digital asset flows. Outbound monitoring should compare actual chain activity with an independently reconstructed set of approved withdrawals. To preserve independence, the monitor should not rely solely on the same command produced by the withdrawal system.

The monitor should derive expected chain, asset, amount, recipient, timing, and wallet from a separate business record. It should aggregate behavior across dimensions that per-transaction limits miss:

• Small test transfers followed by rapid escalation.
• Reuse of new recipients across accounts, assets, or chains.
• A sudden increase in withdrawal velocity or total exposure.
• Simultaneous outflows from multiple operational wallet tiers.
• A shift into native assets that are harder to freeze.
• Differences between the approved request, signed transaction data, and broadcast transaction.

Controls should evaluate cumulative amount, velocity, whether a destination is new, wallet tier, how easily an asset can be converted, and cross-chain behavior over a time window. Bitget's initial ETH and TRX movements illustrate the value of evaluating transactions as a sequence rather than only as isolated events [3]. A high-confidence mismatch should invoke the emergency-response path described in Section 2.4. Lower-confidence anomalies may require a second approval, destination cooling period, reduced limit, or a temporary withdrawal hold.

Inbound monitoring should screen deposits before credit and rescreen them before withdrawal. It should follow funds through bridges, decentralized exchanges (DEXs), intent-based routing services, and intermediate addresses because matching only the first attacker address is insufficient. High-confidence matches need a documented process for holding funds, investigating the match, handling appeals, and completing any legal handoff.

Rapid intelligence sharing among exchanges turns inbound screening into a network effect. One institution may detect the incident while another sees the proceeds. Shared machine-readable indicators and current contacts shorten the interval between attribution and action.

2.4 Emergency Pause and Asset Transfer

The objective is to contain the remaining exposure once a high-confidence security signal or operational fault is identified.

Signals may include privileged-access or command-integrity violations, withdrawal-intent or signing mismatches, abnormal outbound, inbound, or other on-chain activity, and reconciliation failures. The institution should then be able to pause affected signing, broadcast, withdrawal, or wallet operations. If assets remain exposed, it should also be able to move them from the suspected wallet to predefined safe destinations. A pause buys investigation time; a transfer reduces the remaining exposure.

• Independent pause authority: The pause must remain available if the main administration system is compromised. Its scope should be narrow enough to stop a specific chain, wallet, asset, or operation where the architecture allows it. Activation and release require authenticated authority, tamper-resistant records, explicit resume criteria, and testing under degraded conditions.
• Transfer-path continuity: A configuration change must not invalidate the old emergency path before its replacement has been deployed, authorized, signed, stored, and tested.
• Executable transaction readiness: Stored emergency transactions can become stale because of nonce changes, insufficient native-token balance to pay fees, source-asset balance changes, fee-market changes that make signed fee limits unusable, expiry, or configuration updates. Readiness checks should validate these dependencies continuously. Fully signed transaction data should remain encrypted and access-controlled until the emergency action is approved and ready for immediate broadcast.
• Coverage and failover: Every operational wallet, chain, native asset, and supported token needs primary and fallback transfer paths. Broadcast and verification infrastructure also needs redundancy across remote procedure call (RPC) endpoints, operations systems, and manual recovery tools.
• Completion checks and drills: The emergency response procedure should define completion through confirmed on-chain execution, per-asset verification, residual-balance checks, and reconciliation between on-chain state and internal records. It should also detect chain reorganizations and failed transactions. Regular drills should measure the complete recovery time from detection through final balance verification.

An authorized blockchain penetration test can turn cross-layer assumptions into evidence by exercising the running environment within an agreed scope [15]. For production testing, documented Rules of Engagement (RoE) should set authorization, allowed techniques, stop criteria, value limits, communications, evidence handling, and pause authority before testing begins [16].

Conclusion

The Bitget incident was neither a private-key compromise nor a smart contract exploit. Bitget said the attackers exploited a vulnerability in a third-party security product to obtain intranet access credentials, then forged withdrawal commands that the wallet system processed into validly signed on-chain transfers [1, 2]. After assets leave the affected institution, recovery becomes a shared ecosystem effort. The responses from Bitget, Binance, Bybit, THORChain, and NEAR Intents show that participants can respond in different ways [8-12]. How the community can coordinate those capabilities quickly and responsibly when a major security incident or threat emerges remains a broader challenge for the crypto industry.

The known downstream path informs the systematic framework proposed here, which connects prevention and detection with response and recovery. Institutions can reduce dependence on any single safeguard by restricting privileged access and authenticating command origin, reconstructing approved withdrawal intent independently at signing, monitoring outbound sequences and inbound proceeds, and maintaining independently operable pause and transfer paths. Custody remains essential, and these practices complement it across the full money-handling chain [13, 15].

References

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement