Onchain Security Roundup: Sep 21 - Oct 5

Bitget Wallet-Infrastructure Compromise

TL;DR: On the evening of 24 September Bitget's hot and warm wallets on six chains sent most of their balances to one attacker in two hours. Bitget puts the loss at $387.5 million. Bitget says a compromised backend spoofed transaction data through its normal authorisation flow, no private key was stolen, and user balances are unaffected.

Bitget is a centralised exchange, founded in 2018 and one of the larger derivatives venues, that holds customer deposits in hot and warm wallets across dozens of chains and runs a separate non-custodial wallet product under the same name. Like any exchange, its hot wallets sign withdrawals around the clock, so the signing path is always live and the backend that feeds it transactions is the thing to protect.

On 24 September, Bitget's Ethereum hot wallet and a second Bitget-controlled address sent 24,596.6 ETH, 34,751,168 USDT, 12,852,046 USDC and 3,000.32 XAUt to one fresh address, in a handful of transfers that each emptied most of the source wallet. ScamSniffer, which flagged the pattern, counted 12 transfers to the same address on six chains, each taking 90 to 95% of the wallet's balance, with XRP as the largest single leg. Bitget's stated detection time was 18:31 UTC, user withdrawals were halted between 20:10 and 20:40 UTC, and the attacker forwarded the stablecoins onward within half an hour of receiving them.

Bitget says the attacker compromised a critical backend system inside its wallet infrastructure, spoofed transaction data and pushed it through the normal authorisation process. The Bitget team has ruled out private-key compromise and says cold wallets and its separate non-custodial wallet product were untouched. SlowMist's investigation progress report adds that the malicious activity involved third-party security products and the wallet application host, with the earliest signs in August and a dwell time reported at 25 days. Hypernative's analysis found $290 million left within 24 seconds of signing. Bitget and TRM Labs point to North Korea as the likely actor.

Bitget says the losses were absorbed by the exchange, with user balances backed one to one by its Protection Fund. The fund held 5,500 BTC before the attack, fell below $200 million after absorbing the loss, and on 30 September CEO Gracy Chen said it had been topped back up to $309 million with company capital. Withdrawals were restored in phases from 28 September, BTC first, with remaining assets, fiat and P2P from 2 October.

The recovery outlook is thin. BlockSec's fund-flow analysis counts under $1 million frozen and $183 million swapped to ETH within hours, NEAR Intents says it blocked $50 million of attempted routing while THORChain let flows through, and CoinDesk reported $83 million of stolen XRP moved beyond the reach of freeze controls.

Neutron Governance Takeover Drains Astroport and Drop

TL;DR: On 22 September an attacker drained $9.4 million from Astroport and Drop on Neutron after passing an expedited governance proposal that handed them admin rights over 11 contracts. Cosmos Hub validators halted for a day and moved 1,227,121 ATOM of proceeds into a validator multisig, where it remains pending a refund vote. The $1.96 million bridged out is unrecovered.

Neutron is a Cosmos appchain hosting Astroport, its main DEX, and Drop, a liquid-staking protocol. On chains built with the “wasmd” module, chain governance can rewrite the admin of any CosmWasm contract, an authority that sits above whatever multisig or DAO the application itself uses. That governance design was exploited: no underlying contract had a bug.

The proposal record was verified against Neutron's public API. Proposal 9, titled "AIATO: AI Agent Takeover. Phase 1: Agent Admin Registration", was submitted on 19 September on the expedited track with a 1,000,000 NTRN deposit, carrying 11 MsgUpdateAdmin messages that set the admin of Astroport and Drop contracts to the attacker's address. It passed with 37.31 million NTRN in favour, 8.09 million against and 0.17 million veto. 

According to GoPlus's reconstruction, the attacker bought 31.62 million NTRN for $20,199 of USDC eleven minutes before the tally and delegated it, tipping the result. An hour before close they uploaded contract code containing a withdraw-all function, and within 24 minutes of execution they migrated ten contracts to it and emptied them. SlowMist splits the take at $4.9 million from Astroport and $4.4 million from Drop. GoPlus notes that $113,000 of staked NTRN was the economic weight guarding $9.4 million of assets.

The attacker bridged part of the proceeds, including 1.7 million ATOM, to the Hub and began swapping through THORChain. Validators representing over a third of voting power stopped their nodes and the Hub halted at height 33,086,740 on 22 September. After Cosmos Labs wrote a one-line state change into a patched release and two-thirds of voting power confirmed it, the Hub restarted a day later and moved 1,227,121.37 ATOM from the attacker's address into a 4-of-6 multisig held by Nansen, Keplr, Enigma, Silknodes, Kiln and Polkachu.

As of 5 October, the multisig still holds the same balance. A THORChain refund of 168,991 ATOM reached the attacker after the restart and left for Osmosis. $1.96 million bridged out before the halt has not been recovered. Neutron relaunched on 25 September. Refunds to victims await Hub governance. Neutron's promised post-mortem had not been published at the time of this report.

Duelbits Hot Wallet Drain

TL;DR: The crypto casino Duelbits confirmed a $7 million drain from its hot wallets on 24 September. Funds left across five chains within 20 minutes. A private-key compromise is the suspected root cause. Duelbits says user funds are safe. No recovery has been reported.

Duelbits is a centralised crypto casino holding customer and operating funds in multi-chain hot wallets, and this is their second major breach after a $4.6 million incident in 2024. The casino's hot wallets constantly sign to pay out bets, and this makes them hard to protect because the signing path is always live.

On 24 September, 836 ETH left a Duelbits deposit address for a fresh attacker wallet. Ten smaller inbound transfers of 12.7 to 15.2 ETH each followed over the next 20 minutes, a pattern typical of bridged inflows from other chains. At 09:26 UTC the attacker approved 96,830 USDC to a swap router, failed once, and swapped successfully a minute later. ScamSniffer counted $4.2 million across ETH, USDT, USDC, BNB and TRX, then added 8.1 BTC, Specter identified a Solana leg of almost $1 million, and CertiK put the total at $6 million before the Duelbits co-founder confirmed $7 million and took the site offline. By early afternoon the attacker had consolidated 2,234 ETH into one address.

No root cause has been published, but security firms suspect private-key compromise because withdrawals hit five chains almost simultaneously. No recovery or further statement from Duelbits at the time of this report.

NEAR Intents Omni Vault Accounting Exploit on BNB Chain

TL;DR: Between 30 September and 1 October an attacker withdrew 3,865,000 USDT from NEAR Intents' BNB Chain hot vault in five signature-authorised withdrawals, exploiting a deposit-refund accounting bug in its Omni infrastructure. The team paused eleven chains, patched the contract and pledged full compensation. NEAR says the exploiter returned all funds on 2 October.

NEAR Intents is NEAR's settlement layer for cross-chain intents. A user expresses what they want, solvers compete to fill it, and the Omni deposit and withdrawal infrastructure moves assets on and off external chains through hot vaults. The vault on BNB Chain releases funds when presented with a signed withdrawal message derived from the NEAR Intents contract. That design is both convenient and dangerous for the same reason. If the accounting that produces those signatures is wrong, every withdrawal the vault pays out looks perfectly valid onchain.

The attacker's address was funded with 22.76 USDT on 28 September, then tested the vault with withdrawals of 10 and 11 USDT at 18:57 and 20:05 UTC on 30 September. The main drains followed: 800,000 USDT at 23:54 UTC, 1,200,000 at 00:24, 1,500,000 at 00:50 and 330,000 at 01:46 UTC on 1 October, with a final withdrawal of 35,000 USDT at 06:08 UTC. All five, plus the probes, were ordinary calls to the vault's signature-authorised withdraw function, and they sum to 3,865,000 USDT, which matches PeckShield's figure. 

Laundering began within minutes. The attacker swapped USDT to BNB in 100,000 to 300,000 tranches and moved 500,000, 429,999, 329,999 and 34,898 USDT to consolidation addresses, two of which QuillAudits associates with KuCoin deposits. PeckShield reported onward bridging into bitcoin. Address-poisoning spam mimicking those consolidation addresses appeared around the attacker's transfers within minutes, a now-routine hazard for anyone tracing these flows.

NEAR Intents disclosed the incident on 1 October and attributed it to a bug in how its Omni deposit and withdrawal infrastructure interacted with the NEAR Intents contract. The fix pull request supports that account. Per ScamSniffer's reading, its regression test reproduces refund requests exceeding the amount deposited, with the oversized refund log breaking the deposit-resolution callback. Deposits and withdrawals were paused on eleven chains for twelve hours, the contract side was patched, and full compensation was pledged. On 2 October NEAR co-founder Illia Polosukhin said the exploiter had returned all funds, and on 3 October the team closed the investigation.

Meter Unbacked MTRG Mint through the Passport Bridge

TL;DR: On 23 September a block-validation flaw on Meter’s mainnet let an attacker mint unbacked MTR and MTRG, bridge them to BNB Chain through Meter Passport and sell them on PancakeSwap. Blockaid estimates $2.3 million of unbacked wrapped MTRG minted; realised proceeds are unknown. Meter paused the chain and bridge.

Meter is a layer-1 with native token MTR and governance token MTRG, connected to BNB Chain through its Meter Passport bridge. Passport relayers attest to events on Meter mainnet, so the bridge inherits the consensus assumptions of the chain it watches. If Meter's own block validation accepts blocks containing mints that should have been rejected, the bridge faithfully carries an invalid state to BNB Chain. Meter's 2022 Passport hack, a $4.4 million loss, was a bridge-contract bug. This one appears to be a chain-level bug expressed through the bridge, though no technical post-mortem has been published.

On 24 September, the Passport bridge contract minted exactly 1,000,000 wrapped MTRG to an exploiter address, with no corresponding lock visible on the other side. Blockaid's estimate of $2.3 million of unbacked wrapped MTRG across two mint transactions is the conservative, better-documented figure. Because the tokens were unbacked, their face value is not a realised loss. The attacker could only realise what PancakeSwap liquidity existed, and those proceeds are unknown.

Meter paused the mainnet and the bridge, preserved chain state and said the recovery method was still to be decided, leaving open whether it will roll back or socialise the unbacked supply. 

Payy Network Rollup Proof-Verification Exploit

TL;DR: At 04:21 UTC on 24 September a single call to verifyRollup on Payy Network's Ethereum rollup contract released 1,832,149 USDC, the bridge's full balance, to attacker addresses. Phalcon counts $1.93 million across two transactions. Burn records with all-zero hashes point at the proof-verification logic. Payy paused everything and says a compromised key is ruled out.

Payy Network is a privacy payments rollup with card products. User deposits sit non-custodially in an Ethereum contract that verifies rollup proofs and releases USDC on withdrawal. A validity-proof bridge is only as sound as its verifier. If the verifier accepts a withdrawal against a burn commitment that was never produced, the contract pays out exactly as designed.

In one block the attacker's contract called verifyRollup and the rollup contract emitted twelve USDC transfers to three recipients totalling 1,832,149.47 USDC, of which one transfer alone was 1,828,589 USDC. Each transfer is paired with a burn event, and the burn record attached to the largest transfer carries an all-zero hash where a commitment to the burned note should be. Phalcon floated two explanations, a flaw in the zero-knowledge circuit or a compromise of privileged infrastructure such as a prover or sequencer key. Payy's statement on 25 September, reporting its initial root-cause analysis, rules out a compromised key, social engineering and any exploit of its off-chain infrastructure, which leaves the verification path. Phalcon's $1.93 million total includes a second, smaller transaction. Protos reports the attacker was funded through Railgun, and PeckShield reports the stolen USDC was swapped to 683 ETH and split across three addresses.

Payy paused all operations including cards, notified law enforcement and said the funds were users' non-custodial deposits. It is validating its root-cause analysis with an audit firm but has not released the report or reimbursement plan yet.

Limit Break Payment Processor V2 Legacy-Approval Exploit

TL;DR: From 24 September an attacker exploited a sender-spoofing bug in Limit Break's Payment Processor V2 to spend token approvals Magic Eden users granted in 2024, taking 530.7 WETH from 911 wallets per Cryptoticker. Whitehat 0xQuit swept 23,155 NFTs worth $5.7 million to safety. BeInCrypto reports $3.4 million of the $6.6 million at risk has since been returned.

Payment Processor is Limit Break's marketplace settlement protocol, which Magic Eden's EVM marketplace used the V2 of from February to October 2024. Listing on that marketplace required a token approval to the Payment Processor contract, and approvals do not expire when a marketplace changes backends. Two years later, a bug in V2 allowed transfers to be triggered on behalf of the wrong sender. A victim's onchain message and Magic Eden's advisory both describe it as a sender-spoofing exploit, so anyone could spend approvals granted in 2024. 

The whitehat 0xQuit flagged the first thefts, 10 Meebits, 50 Otherdeeds, 10 World of Women and 235 Desperate ApeWives, then used the same vulnerability defensively to sweep exposed NFTs into a rescue wallet before the attacker could reach them. Magic Eden says 23,155 NFTs were secured and can be reclaimed. 0xQuit's onchain message puts the figures near 26,000 and $5.7 million. With the NFTs secured, the attacker turned the same exploit on WETH approvals, where no defensive sweep was possible because rescuing fungible tokens means taking custody of them. 0xQuit estimated 660 WETH was exposed; a copycat bot front-ran the attacker and took 260 WETH, which it has since been returning to victims. Cryptoticker counted 530.7 WETH taken from 911 wallets by 26 September. 

The MEV bot that front-ran the attacker has been returning WETH to victims, and BeInCrypto reports $3.4 million of the $6.6 million at risk has been returned. The exposure is not closed. A further 4.9 WETH was taken on 30 September from an approval granted in 2024. Limit Break paused the current version of the contract as a precaution. Users should always revoke approvals to contracts to prevent these types of losses.

TradeWiz Telegram Bot Private Key Compromise on Solana

TL;DR: On 30 September an attacker swept 20,933 user wallets of the Solana Telegram trading bot TradeWiz, taking 3,523 SOL plus rent and tokens worth $459,000 per Bitquery. TradeWiz attributed the loss to a private-key export feature of sister product $SOL PVP, began refunds that evening, and filed a police report.

Telegram trading bots trade custody for speed. The bot generates a wallet for each user, keeps the private key and executes trades on instruction. Users typically hold only what they are actively trading. That is why a single operator compromise produces thousands of small losses rather than a few large ones, and TradeWiz is one of the larger such bots on Solana.

Bitquery's investigation gives the clearest reconstruction. A 34 SOL test sweep ran at 18:40 UTC on 28 September. The main sweep began at 13:25 UTC on 30 September and ran for two and a half hours, impacting 20,933 wallets and taking 3,523 SOL, 189 SOL of reclaimed rent and $14,000 of SPL tokens to a collector address and a second wallet ($459,000 at a SOL price of $120). Bitquery also noted the attacker had been a TradeWiz customer first and that the first cash-out was 100 SOL through a forwarder to an address it identifies as a KuCoin deposit on 1 October. The collector wallet still held 1,584.7 SOL on the morning of 5 October, consistent with Bitquery's observation that most of the stolen SOL had not moved.

TradeWiz posted a security notice on 30 September attributing the exposure to the private-key export feature of its sister product $SOL PVP, which it disabled. It said first refunds went out at 18:08 UTC the same day and filed a police report on 1 October. The team has not explained how exported keys became available to an outsider. 

Two Safes Drained through Third-Party FlashLoopAdapter Module

TL;DR: On 1 October an attacker extracted 114.096 ETH ($305,000) from two Safe wallets running leveraged weETH loops on Aave V3 through a third-party module called FlashLoopAdapter. The module authenticated callers by trusting the caller's own claim that it was enabled, which any attacker contract could fake. The victims offered a 10% bounty onchain; no return has been observed.

Safe modules are contracts that can be enabled to act on the Safe's behalf without a fresh signature each time. They are useful for automation but add potential risk vectors, as they hold standing authority over the Safe's assets. FlashLoopAdapter existed to open and close leveraged positions: borrow WETH on Aave V3 against weETH, loop, and unwind in one transaction using a flash loan.

The module's open and close functions authenticated callers by asking the caller itself whether the module was enabled and trusting the answer. The module authenticated callers by trusting the caller's own claim that it was enabled, which any attacker contract could fake. The attacker deployed a fake Safe that did just that, then used the module's standing privileges over the two real Safes to unwind their positions. Per the analysts' reconstruction, a WETH flash loan from Morpho repaid 1,335 WETH of the Safes' Aave debt, releasing 1,306.48 weETH from one Safe and 6.4 weETH from the other, which was swapped before the loan was repaid. At 15:08 UTC on 1 October the attack transaction closed with 114.096 ETH unwrapped and forwarded to the attacker's wallet. Aave confirmed Aave V3 was not exploited. The protocol saw a legitimate repayment and withdrawal from an account that had authorised the module. Safe's core contracts were equally unaffected.

The victims posted an onchain message offering to let the attacker keep 11.41 ETH if 102.69 ETH came back by 18:00 UTC on 3 October. The deadline passed without a public update. 

GoldPesa Uniswap v4 Hook Exploit on Base

TL;DR: On 2 October an attacker drained GoldPesa's protocol-owned GPX/USDC liquidity on Base by triggering its Uniswap v4 hook's hourly rebalance from inside their own transaction, clearing 114,428 USDC profit and swapping it to 96,389 USDT. Uniswap v4 behaved as designed.

Uniswap v4 moved the exchange onto a single PoolManager contract and allowed pool deployers to attach hooks, custom contracts that run at defined points in a swap or liquidity change. GoldPesa, issuer of the gold-linked token GPX, ran its protocol-owned GPX/USDC liquidity through a hook that rebalanced the position inside beforeSwap on an hourly cadence.

GoldPesa used a Uniswap v4 hook to manage and rebalance the GPX/USDC liquidity. Its constructor deploys the GPX token (CREATE2-ground so its address sorts below USDC, making GPX currency0), receives the entire 100M supply, creates the GPX/USDC pool with itself as the hook (fee 0, the hook charges its own 1% fee in beforeSwap and splits it four ways), and mints one liquidity position from the current price up to MAX_TICK. The source banner declares it "100% trustless DeFi - No owner... cannot be paused, modified, or censored." That immutability is why nothing could be done once the vulnerability was found.

The strategy it automates is a ratcheting price floor. At most once per hour, it burns its position and re-mints one tick higher at the bottom, feeding in more GPX from reserves as demand grows: ‘beforeAddLiquidity/beforeRemoveLiquidity’ revert for everyone unless an internal ‘isRebalancing’ flag is set, so the hook's own position is the pool's only liquidity.

According to Defimon and SlowMist, the hook's rebalance performed liquidity operations through Uniswap v4's shared, flash-accounted PositionManager while execution sat inside a PoolManager unlock the attacker had opened. The hook never verified how the resulting GPX and USDC balances would be settled. The attacker waited for the hourly window, fired the rebalance from inside their own transaction and settled the protocol's position in their own favour.

On 2 October, the attacker's contract opened a 175,000 USDC flash loan from Morpho, triggered the rebalance, repaid the loan in full within the same transaction and came out 114,428 USDC ahead, which it immediately swapped into 96,388 USDT and forwarded to the attacker's wallet. SlowMist's figure of 114,999.999 USDC for the protocol liquidity taken is consistent with that decode. 

Cryptotimes reports the proceeds then moved as USDT across Solana and BNB Chain.

Uniswap v4's PoolManager and PositionManager acted as designed; the flaw sat entirely in the third-party hook. There has been no statement from GoldPesa, and no recovery has been reported.

MetaMask Staking Infrastructure Compromise

TL;DR: MetaMask disclosed on 30 September that part of its validator infrastructure, formerly Consensys Staking, had been compromised, and began precautionary exits of affected Ethereum validators, including those run for Lido. Researcher 0xKaden reports 0.36 ETH of block rewards were diverted to a Tornado-funded address; no stake was lost. Lido says stETH holders need take no action.

Ethereum staking separates two important pieces of information. The validator signing key proposes and attests to blocks and lives on the operator's infrastructure; the withdrawal credential decides where the stake goes and, for Lido validators, points at Lido's contracts. An attacker who compromises an operator therefore cannot withdraw the stake. What they can do is misbehave on the validators' behalf, which risks slashing, and redirect the execution-layer tips and MEV that flow to whatever fee recipient the validator client is configured with.

MetaMask's notice and Lido's parallel disclosure say only that a security incident affected part of MetaMask Staking's validator infrastructure and that affected validators were being exited as a precaution, out of the normal exit order. Independent researcher 0xKaden added the detail: 18 of 19 block proposals from affected validators paid their rewards, 0.36 ETH in total, to a fee recipient funded from Tornado Cash. The address was first funded with 0.0978 ETH from the Tornado Cash 0.1 ETH pool on 30 September, five hours before the disclosure, and still held the diverted rewards.

The potential scale is why this could be critical. Kaden counts 17,000 validators holding 523,000 ETH ($1.4 billion) entering the exit queue, which had swelled to 850,000 ETH with a wait of around 15 days by 4 October per KuCoin and CoinDesk. Lido expects the exits to complete around 7 October, with ETH returning to the protocol within 45 days, and says its reserve of more than 6,750 stETH absorbs any foregone rewards or minor penalties. No slashing has been reported, MetaMask says wallet users and funds are unaffected, and the intrusion vector has not been disclosed.