~$418M Lost: Bitget, NEAR Intents Exploits

During the past two weeks (2026/09/21 - 2026/10/04), 8 blockchain security incidents caused total estimated losses of approximately $418.4M.

Date	Incident	Type	Estimated Loss
2026/09/23	Meter Passport	Block Validation Flaw	~$2.3M
2026/09/24	Payy Network	Suspected Proof-System Soundness Flaw	~$1.9M
2026/09/24	Limit Break	Improper Calldata Validation	~$7.7M
2026/09/24	Duelbits	Root Cause Undisclosed	~$7M
2026/09/24	Bitget	Third-Party Security Product Vulnerability	~$387.5M
2026/09/27	DYORSwap	Insufficient Network Configuration Verification	~$2.1M
2026/09/30	NEAR Intents	Improper Refund Validation and Missing Rollback	~$3.9M
2026/10/04	Unnamed Base Vault	Improper Access Control	~$6M

Reasons for selection

Bitget: The incident accounts for most of the period's losses and traces an off-chain compromise through forged withdrawal commands to valid on-chain transfers, without a private-key or smart-contract compromise.
NEAR Intents: A refund validation flaw and missing state rollback turned failed cross-chain deposit resolution into unbacked internal balances that could pass the normal withdrawal path.

Bitget

On September 24, approximately $387.5M left parts of Bitget's hot and warm wallet infrastructure across Ethereum and other EVM networks, XRP Ledger, Zcash, and TRON. The on-chain transactions carried valid wallet signatures. Bitget said the attacker exploited a vulnerability in a third-party security product, obtained intranet access credentials, and forged withdrawal commands, while private keys and cold wallets remained secure[1][2].

Incident Overview

Independent investigations add detail to the attack path without naming the two affected security products. The earliest malicious activity identified on Product A dates to August 31, when a zero-day affected a service on one node. The attacker also gained privileged access to two security appliances, deployed a web shell and established a command-and-control connection on Product B, and moved laterally to the production wallet job server.

The attacker used an internal employee identity to access Product B's management platform. Investigators also recovered a customized withdrawal tool that forged risk-control parameters, constructed withdrawal requests, and invoked the withdrawal process. How the attacker moved between all involved systems remained under investigation. The public chains recorded the final signed transfers, not these upstream operations.

On-chain records show that the first movements were 93 TRX and, 11 seconds later, 0.84 ETH at 18:31 UTC. Bitget's current timeline records reconciliation detection at 19:05 UTC and activation of its highest-level emergency response at 19:14 UTC[1]. A separate 20.59M TRX transfer reached the attacker-controlled TRON address at 19:16 UTC; Chen described 17 larger transfers across eight other networks totaling approximately $361M[3]. Containment began at 19:40 UTC, and wallet withdrawal and signing services were shut down at 21:44 UTC[1].

Fund Status and Community Response

At 16:35:28 UTC on September 29, Bitget's official holdings tracker reported $322.67M in current attacker holdings, about $632,700 frozen, $312,500 in issuer-freezable stablecoins, and $55.87M in transit or still under analysis. Its separate address view showed balances concentrated in BTC ($288.51M), ZEC ($28.91M), and ETH ($7.17M); that view uses a different classification scope from the overview.

Binance shared intelligence and supported fund tracing, while Bybit updated LazarusBounty and offered assistance[4][5]. Infrastructure providers made different choices. Bitget asked THORChain to refuse service to listed attacker addresses, arguing that decentralization should not shield the circulation of known stolen funds[6]. THORChain rejected selective blacklisting and said its controls could halt broader activity or a chain route, not one address or transaction[7].

NEAR Intents reported that SHIELD identified and blocked more than $50M in attempted attacker-linked flows after filtering duplicates. Approximately $503,000 was frozen during execution and about $166,000 passed through; the $50M figure is attempted flow, not a frozen or recovered amount[8]. The tracker later classified $293,507 as frozen at NEAR Intents, and public sources do not reconcile the difference.

Lessons Learned

The attacker entered through third-party security products, reached the wallet job server, and turned forged withdrawal requests into validly signed transactions. Any third-party product with that reach belongs to the effective asset-security boundary: institutions should isolate it, restrict identities and privileges, monitor its behavior, and independently verify withdrawal intent before signing.
Recovery authority was fragmented across exchanges, stablecoin issuers, routing services, and base protocols, so no participant could manage the response alone. The affected institution needs to share verified addresses and transaction data quickly, while infrastructure providers and security teams coordinate tracing, freezing, transaction screening, and recovery within their technical and governance constraints.
For the preventive controls derived from this incident, see Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contracts, which develops a defense-in-depth framework for privileged access, withdrawal intent, asset-flow monitoring, and emergency response.

NEAR Intents

Between September 30 and October 1, NEAR Intents lost approximately $3.87M after a refund validation flaw and a missing state rollback in intents.near created an internal balance without corresponding asset backing. The attacker used that balance to obtain valid HOT MPC withdrawal signatures and release real USDT from the protocol's BNB Chain vault[9][10].

Background

NEAR Intents is an intent execution system on NEAR. Its core contract, intents.near, holds omni-assets, records users' internal balances, and processes asset swaps and withdrawals based on signed intents.

For a cross-chain deposit, a vault on the source chain locks the real asset. Omni creates the corresponding omni-asset on NEAR and transfers it to intents.near, which credits the user's internal balance.

For a withdrawal, intents.near asks Omni to burn the corresponding omni-asset and create a withdrawal record. HOT MPC verifies that record and issues a signature. The destination-chain vault verifies the signature before releasing the real asset. This process requires the internal balances recorded by intents.near to remain backed by the omni-assets the contract actually holds.

Vulnerability Analysis

The deposit path credited the receiver's internal balance before the cross-contract transfer had been fully resolved. During resolution, resolve_deposit_internal() limited the receiver-controlled requested_refund by the receiver's total balance for that token, but not by deposited, the amount actually transferred in the deposit being resolved. The total balance showed only what the account could pay; deposited defined what this transfer was allowed to refund. Without that second bound, a receiver with a large pre-existing balance could request a refund far above the current deposit[10].

For a batched deposit with many long token IDs, the incorrect refund values enlarged the serialized MtBurnEvent. The check_refund().unwrap_or_panic_display().emit() path then panicked when the event exceeded NEAR's total log-length limit, causing the mt_resolve_deposit receipt to fail.

The internal balance had been credited in an earlier receipt. The panic rolled back the callback receipt's attempted balance and supply deductions, but it did not reverse that earlier credit. Omni then returned the transferred assets to the sender, leaving the attacker with a withdrawable internal balance that no longer matched the omni-assets held by intents.near. The vulnerability combined a refund validation flaw with missing state rollback across the asynchronous receipt sequence.

Attack Analysis

The following reconstruction is based on publicly available information[11].

Phase 1: Create an Unbacked Internal Balance on NEAR

Step 1: The attacker deposited 10 USDT through the BNB Chain Omni/HOT vault, giving the malicious receiver account a non-zero omni-asset balance on NEAR.
Step 2: The attacker called mt_batch_transfer_call() on v2_1.omni.hot.tg. In mt_on_transfer(), intents.near first credited the receiver through deposit(), then notified the malicious receiver and passed its response to mt_resolve_deposit().
Step 3: The malicious receiver returned a requested_refund far above the current deposit. Because the validation used the receiver's total token balance as its cap, the abnormal value proceeded into refund processing.
Step 4: Across the batched entries, the oversized refund values made the serialized MtBurnEvent exceed NEAR's total log-length limit. The mt_resolve_deposit callback panicked, which rolled back its attempted refund deductions but not the internal credit committed by the earlier receipt. Omni returned the transferred assets, while the credited balance remained available in intents.near. Repeating this sequence created an unbacked balance that the attacker could withdraw.

Phase 2: Withdraw Real Assets from the BNB Chain Vault

Step 5: At 18:57 and 20:05 UTC on September 30, the attacker used valid HOT MPC authorizations to test the BNB Chain vault with withdrawals of 10 USDT and 11 USDT. The first test transaction confirmed that the vault accepted the upstream authorization.

Step 6: From 23:54 UTC on September 30 through 06:08 UTC on October 1, the attacker made five larger withdrawals of 800,000 USDT, 1.2M USDT, 1.5M USDT, 330,000 USDT, and 35,000 USDT. These transactions released a total of 3.865M USDT from the vault.

Conclusion

NEAR Intents was exploited through incorrect refund validation and a missing rollback after deposit resolution failure. The attacker used oversized refund requests to preserve internal credit after the underlying assets had been returned, then used that unbacked balance to request withdrawals. Omni created the corresponding withdrawal records, HOT MPC signed them, and the BNB Chain vault released real USDT.

Refund processing should cap each token's refund by the amount in the deposit being resolved. The protocol should also make balance crediting and resolution atomic where possible, or apply a guaranteed compensating rollback after failure. Before issuing withdrawal signatures, it should reconcile aggregate internal balances against actual omni-asset holdings and pause withdrawals on any mismatch. Event generation must also be bounded so that an oversized log cannot abort a state-critical resolution path.

References

[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response

[2] https://x.com/GracyBitget/status/2104515761691939026

[3] https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] 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

[5] https://x.com/benbybit/status/2103328213141508335

[6] https://x.com/GracyBitget/status/2103812967066439817

[7] https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[8] https://x.com/GracyBitget/status/2104602301503816040

[9] https://x.com/near_intents/status/2105642219357241796

[10] https://github.com/near/intents/pull/362

[11] https://x.com/Phalcon_xyz/status/2105680009687957909

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.