[{"data":1,"prerenderedAt":37},["ShallowReactive",2],{"scalebit-home-blogs":3},[4,18,28],{"slug":5,"category":6,"categoryLabel":7,"subcategoryLabel":8,"authorName":9,"title":10,"excerpt":11,"contentHtml":12,"coverUrl":13,"publishedAt":14,"readTime":15,"cover":13,"hasCover":16,"coverAlt":17},"near-intents-exploit-analysis-how-3-865m-usdt-was-withdrawn-through-omni-s-cross-chain-infrastructure-da7ed3","research","Research","Incident Analysis","Olivia","NEAR Intents Exploit Analysis: How 3.865M USDT Was Withdrawn Through Omni's Cross-Chain Infrastructure","On October 1, 2026, NEAR Intents disclosed a security incident involving approximately $3.8 million in assets. The exploit affected the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contracts, allowing an attacker to withdraw funds from a vault on BNB Chain.","\u003Cp class=\"docx-align-justify\">On October 1, 2026, NEAR Intents disclosed a security incident involving approximately $3.8 million in assets. The exploit affected the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contracts, allowing an attacker to withdraw funds from a vault on BNB Chain.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On-chain records show that the activity began on September 30. The attacker first executed two small test withdrawals before making five larger withdrawals over approximately six hours, extracting a total of 3,865,000 USDT. Each transaction carried a withdrawal proof in the expected format and was accepted by the vault contract.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Following the incident, NEAR Intents suspended certain cross-chain services and patched the affected contracts. On October 2, project lead Alex Shevchenko announced that the stolen funds had been fully returned.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Although the funds were recovered, the incident raises important questions about how cross-chain systems manage withdrawal authorization, asset balances, and settlement across different networks.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This analysis examines the publicly documented Omni Bridge architecture, the observed transaction sequence, and the security checks that matter when multiple contracts and validators are responsible for a single cross-chain withdrawal.\u003C\u002Fp>\n\u003Ch2>1. How Omni Bridge Handles Cross-Chain Withdrawals\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">NEAR Intents uses an intent-based execution model that allows users to exchange assets across networks by submitting signed transaction intents.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The related Omni infrastructure manages assets through contracts deployed on supported blockchains and an accounting system operating on NEAR.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the public HOT Omni Bridge documentation, the architecture consists of three main components.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>Locker Contracts\u003C\u002Fstrong> hold assets deposited on supported networks and release them when valid withdrawal requests are submitted. On EVM-compatible chains, these contracts manage ERC-20 transfers, verify withdrawal signatures, and execute asset releases.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>HOT Omni Balance\u003C\u002Fstrong> maintains cross-chain asset balances on NEAR. It handles token minting, burning, and transfers, and serves as a source of accounting state for deposits and withdrawals.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>HOT MPC Validators\u003C\u002Fstrong> verify cross-chain events and withdrawal records before producing signed proofs. Destination-chain contracts use these proofs to determine whether a withdrawal has been authorized.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">During a normal deposit, a user transfers assets to a Locker contract on the source chain. The contract records the deposit and assigns a nonce. Once validators confirm the deposit, the corresponding balance can be credited or minted on NEAR.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Withdrawals follow the reverse process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A user submits a withdrawal request on NEAR. Omni Balance processes the corresponding balance deduction or token burn, records the withdrawal, and assigns a nonce. After validators verify the record, they generate a signed withdrawal proof.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The user or an execution service then submits the withdrawal parameters and signature to the destination-chain Locker, which verifies the proof and nonce before releasing the assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The documented flow can be summarized as:\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Ccode>Withdrawal Intent → Balance Debit\u002FBurn → Withdrawal Record → MPC Signature → Locker Verification → Asset Release\u003C\u002Fcode>\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">One important aspect of this architecture is the separation between \u003Cstrong>asset accounting and final settlement\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The destination-chain Locker relies on the withdrawal proof it receives, while the user's complete asset entitlement is maintained by upstream components.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The security of this process therefore depends on the upstream system generating withdrawal records that accurately reflect authorized changes in user balances.\u003C\u002Fp>\n\u003Ch2>2. Attack Timeline: Seven Withdrawals From the BNB Chain Vault\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">According to the public on-chain investigation, the attacker-controlled addresses began preparing for the exploit on September 28, including a 10 USDT deposit into the targeted vault.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On September 30, the attacker executed two small test withdrawals of 10 USDT and 11 USDT. Both were successful.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The attacker then proceeded with five larger withdrawals.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Time (UTC)\u003C\u002Fth>\n\u003Cth align=\"right\">Amount\u003C\u002Fth>\n\u003Cth>Transaction\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Sep 30, 18:57\u003C\u002Ftd>\n\u003Ctd align=\"right\">10 USDT\u003C\u002Ftd>\n\u003Ctd>Test withdrawal\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sep 30, 20:05\u003C\u002Ftd>\n\u003Ctd align=\"right\">11 USDT\u003C\u002Ftd>\n\u003Ctd>Test withdrawal\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sep 30, 23:54\u003C\u002Ftd>\n\u003Ctd align=\"right\">800,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x9fe58e031f73bbd880c782bc9e7446bcda32cadb304a729209871a4a81856c4c\" rel=\"nofollow\">0x9fe58e…6c4c\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 00:24\u003C\u002Ftd>\n\u003Ctd align=\"right\">1,200,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x0381265d6a1bb09de899f49f410a8b907cd548358a7e3c91076c3a52656b8220\" rel=\"nofollow\">0x038126…8220\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 00:50\u003C\u002Ftd>\n\u003Ctd align=\"right\">1,500,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x69d1c68c7e961a0199d3c9f3b6a31cb168ed775ef34b51a42762253ac1efcceb\" rel=\"nofollow\">0x69d1c6…cceb\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 01:46\u003C\u002Ftd>\n\u003Ctd align=\"right\">330,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x9c10b967da0c85631ec105e3b322c0a851fcd01b69ff58f860e5cce003a\" rel=\"nofollow\">0x9c10b9…003a\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 06:08\u003C\u002Ftd>\n\u003Ctd align=\"right\">35,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x16ddfa695b9525662b8e57c35723f44af89b4e7fc2dedc3634f730caf8b90c02\" rel=\"nofollow\">0x16ddfa…0c02\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp class=\"docx-align-justify\">The five larger transactions totaled 3,865,000 USDT, with another 21 USDT withdrawn during the initial tests. The approximately $3.8 million figure reported by the project was an initial estimate.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The investigation also found that only 10 USDT in previous BNB Chain deposits could be traced to the attacker-related addresses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">However, this does not establish the full balance held by those addresses within the cross-chain system. Assets may have originated from other supported networks, earlier transfers, or cross-chain swaps.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The more relevant finding is that all seven withdrawals used proofs with the expected structure, and the destination-chain vault accepted the requests.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The BNB Chain transactions establish that the funds were released. They do not, by themselves, explain why the upstream system generated or accepted the corresponding withdrawal authorizations.\u003C\u002Fp>\n\u003Ch2>3. Signed Withdrawals: What Does the Vault Actually Verify?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">In Omni's documented architecture, a destination-chain Locker verifies a signed withdrawal proof before releasing funds.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The public HOT Protocol EVM repository includes a relevant \u003Ccode>MetaWallet\u003C\u002Fcode> implementation with withdrawal execution, signature verification, and nonce management.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the published implementation, the contract uses ECDSA signature verification and a configured \u003Ccode>verifyAddress\u003C\u002Fcode> to determine whether the submitted proof comes from an authorized signer.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The withdrawal data includes information such as the asset, recipient, amount, and nonce. The contract also checks whether a nonce has already been used.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Each of these checks serves a different purpose.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Signature verification establishes whether the authorization satisfies the contract's cryptographic requirements.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Nonce validation prevents the same withdrawal authorization from being executed more than once within its defined scope.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Parameter binding ensures that a valid proof cannot be reused for a different recipient, asset, amount, or execution environment.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">However, a successfully verified signature does not necessarily establish that the underlying withdrawal is economically valid.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Consider a case where an upstream component incorrectly approves a withdrawal that is not supported by the user's available balance.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">If that withdrawal is recorded and signed through an otherwise authorized process, the destination-chain contract may still accept the proof and release the requested assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">From the Locker's perspective, the signature satisfies its authorization rules. Whether the corresponding assets were correctly deducted from the user's balance depends on the upstream verification process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This creates a trust boundary between \u003Cstrong>withdrawal authorization and asset accounting\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">It is an important area for cross-chain security reviews because the destination-chain contract generally cannot reconstruct every relevant balance change from another network.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This is an architectural risk scenario, not a confirmed description of how the NEAR Intents exploit was executed. The available evidence does not establish that the MPC validators incorrectly signed a withdrawal, that a signature was forged, or that the nonce mechanism failed.\u003C\u002Fp>\n\u003Ch2>4. Root Cause: What Has Been Confirmed?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">NEAR Intents confirmed that the vulnerability involved the interaction between Omni's deposit and withdrawal infrastructure and the NEAR Intents smart contracts.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Based on the public architecture, three areas are particularly relevant to the technical investigation.\u003C\u002Fp>\n\u003Ch3>Withdrawal Authorization and Balance Accounting\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">A valid withdrawal should correspond to an authorized deduction or burn of the user's assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Before generating a withdrawal proof, the system needs to establish that the user has sufficient available funds and that the corresponding accounting operation has been completed according to protocol rules.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where multiple contracts maintain balances or withdrawal records, the system must also ensure that account identifiers, asset types, amounts, and state versions remain consistent.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Any discrepancy between the record used to authorize a withdrawal and the balance state supporting it can create an opportunity for incorrect settlement.\u003C\u002Fp>\n\u003Ch3>Withdrawal Proof Generation and Verification\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">The HOT Omni Bridge documentation describes a process in which validators inspect withdrawal records, generate signatures, and submit those proofs for verification on the destination chain.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A security review needs to examine which contract state validators read, which parameters are covered by each signature, and whether a previously signed request can be modified, revoked, or executed more than once.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Fields such as \u003Ccode>chainId\u003C\u002Fcode>, \u003Ccode>token\u003C\u002Fcode>, \u003Ccode>amount\u003C\u002Fcode>, \u003Ccode>recipient\u003C\u002Fcode>, and \u003Ccode>nonce\u003C\u002Fcode> should be bound to the correct authorization context.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The precise set of signed fields must be verified against the deployed implementation. The presence of a field in an application-level withdrawal request does not automatically mean it is included in the signed message.\u003C\u002Fp>\n\u003Ch3>Settlement Consistency\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">A correctly formatted withdrawal proof must correspond to an authorized asset movement within the cross-chain system.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The protocol needs to prevent duplicate settlement and ensure that the same underlying asset entitlement cannot be used repeatedly.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This becomes particularly important when cross-chain messages are delayed, transactions are retried, state updates arrive out of order, or only part of a multi-step withdrawal succeeds.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These conditions need to be addressed at the protocol level because different components may observe and process state changes at different times.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">As of this analysis, a complete technical post-mortem identifying the vulnerable function and full exploitation conditions has not been independently verified.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The confirmed root-cause scope therefore remains the interaction issue between the Omni infrastructure and the NEAR Intents contracts.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The available evidence does not justify attributing the incident specifically to signature forgery, MPC key compromise, nonce replay, or a particular balance-update bug.\u003C\u002Fp>\n\u003Ch2>5. Tracing the Stolen Funds Across Networks\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">After withdrawing USDT from the BNB Chain vault, the attacker converted the assets into BNB and distributed them across newly created wallets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the public investigation snapshot taken on October 1 at 14:30 UTC, a substantial portion of the funds had moved toward Bitcoin and centralized exchanges.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Approximately 34.69 BTC was identified across four Bitcoin wallets, representing around 76% of the stolen value at the exchange rates used in the investigation. Approximately $802,000 was also traced to KuCoin-related deposit addresses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Another notable detail is that the attacker reportedly processed approximately $822,000 through NEAR Intents' own cross-chain swapping service during the incident.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Some of those operations involved transferring around 750 BNB to the same BNB Chain vault associated with the exploit, then receiving ETH or BTC through the normal cross-chain exchange process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These swaps were part of the subsequent movement of funds. Their execution alone does not establish that the original vulnerability was exploited again.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Cross-chain fund tracing requires correlating source-chain transfers, swap orders, destination-chain receipts, and transaction timestamps.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where complete swap records are unavailable, matching amounts and timestamps can support an investigation, but they cannot independently prove every step in a transfer path.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The reported destinations also reflect funds observed at different stages of movement. They should not be treated as mutually exclusive balances or added together as separate losses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Most importantly, the October 1 snapshot describes the movement of funds before recovery. It does not represent their final ownership or location.\u003C\u002Fp>\n\u003Ch2>6. Incident Response and Recovery\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">On October 1, NEAR Intents acknowledged the security incident and stated that the relevant contract issue had been patched.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Certain deposit and withdrawal services remained suspended while the team continued its response to the affected Omni infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On October 2, NEAR Intents project lead Alex Shevchenko announced that the approximately $3.8 million in stolen funds had been fully returned and that the related investigation would be closed.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Subsequent public reporting identified a return transaction of approximately 34.6 BTC to a Bitcoin address designated by the project.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The complete return paths for the remaining assets have not been independently reconstructed from the publicly available information. Accordingly, the full recovery is presented here as the project's confirmed statement, with the directly observable Bitcoin transaction treated separately.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The incident affected infrastructure supporting NEAR Intents' cross-chain deposit and withdrawal operations.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">There is no public evidence in the reviewed material that NEAR's underlying consensus network was compromised or that the NEAR native token suffered a corresponding protocol-level vulnerability.\u003C\u002Fp>\n\u003Ch2>7. ScaleBit Security Insight: What Should a Cross-Chain Security Audit Cover?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">The NEAR Intents incident involved several components that participate in the same asset transfer: vault contracts on different networks, a shared accounting system on NEAR, withdrawal proof generation, and final settlement.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A Cross-Chain Security Audit should examine these components as a complete execution flow.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Ccode>Deposit → Balance Accounting → Withdrawal Authorization → Settlement\u003C\u002Fcode>\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Several security invariants are particularly important.\u003C\u002Fp>\n\u003Ch3>Withdrawal Authorization Consistency\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Every authorized withdrawal should correspond to a valid asset debit or burn.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The recipient, token, amount, and destination network in the withdrawal proof must match the transaction being settled.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Testing should cover concurrent requests, multiple accounts, different assets, and changes in authorization state while withdrawals are pending.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where different components maintain separate records, the audit also needs to establish how those records are reconciled.\u003C\u002Fp>\n\u003Ch3>Nonce Uniqueness and Replay Protection\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Each withdrawal nonce should be unique within its intended authorization domain and unusable after successful settlement.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The review should also verify that signatures are bound to the correct chain, contract, asset, and recipient.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This matters when a protocol deploys similar contracts across multiple networks or supports several withdrawal paths using shared signing infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A valid proof must not become executable in an unintended context.\u003C\u002Fp>\n\u003Ch3>Cross-Chain Asset Conservation\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">The assets released through cross-chain settlement must remain consistent with valid changes in user balances and the system's available reserves.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Testing should cover individual withdrawals as well as aggregate asset accounting across networks.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Message delays, failed transactions, retries, and different execution orders must not allow the same asset entitlement to support multiple successful withdrawals.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Asset Conservation testing is particularly important when deposits and withdrawals are processed asynchronously.\u003C\u002Fp>\n\u003Ch3>Failure-State Testing and PoC Verification\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Cross-chain systems need to be tested beyond their normal execution paths.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Relevant cases include a withdrawal request that has been recorded but not yet signed, a signed proof awaiting execution on the destination chain, a failed settlement transaction that is subsequently retried, or a change in upstream state after a proof has already been issued.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These scenarios can be examined using state-transition testing, Fuzz Testing, and PoC Verification.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The goal is to verify that different components preserve their security invariants even when messages, transactions, and state updates occur in unexpected sequences.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">For more complex protocols, testing should also account for validator configuration changes, contract upgrades, and the interaction between old and new withdrawal states.\u003C\u002Fp>\n\u003Ch2>8. Conclusion\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">The funds involved in the NEAR Intents incident have been reported as fully recovered, but the disclosed vulnerability involved a critical part of cross-chain infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">In systems that rely on external validators and cross-chain messages, signature verification, balance accounting, and settlement need to remain consistent throughout the withdrawal process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">When these responsibilities are distributed across multiple contracts or networks, security testing must examine how they interact under both normal and abnormal execution conditions.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">ScaleBit, a sub-brand of BitsLab, focuses on vulnerabilities in DeFi protocols, cross-chain infrastructure, and complex smart contract interactions.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Our Smart Contract Security Audit work covers authorization logic, cross-contract execution paths, asset accounting, state consistency, and PoC-based vulnerability verification [\u003Ca href=\"https:\u002F\u002Fwww.bitslab.xyz\u002Ffaq\" rel=\"nofollow\">BitsLab AI\u003C\u002Fa>].\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">For teams building or upgrading cross-chain and DeFi protocols, learn more about our security research and audit services at \u003Ca href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\" rel=\"nofollow\">ScaleBit\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fwww.bitslab.xyz\u002Faudit\" rel=\"nofollow\">BitsLab\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>References\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fx.com\u002Fnear_intents\u002Fstatus\u002F2105642219357241796\" rel=\"nofollow\">NEAR Intents: Public Incident Announcement\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fdocs\u002Fblob\u002Fmain\u002Fomni-tokens\u002FREADME.md\" rel=\"nofollow\">HOT Omni Bridge: Architecture and Deposit\u002FWithdrawal Documentation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fdocs\u002Fblob\u002Fmain\u002Fhot-omni-balance.md\" rel=\"nofollow\">HOT Omni Balance Documentation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fomni-wallet-solidity\" rel=\"nofollow\">HOT Protocol: EVM Contract Repository\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fbitquery.io\u002Finvestigations\u002Fnear-intents-hack\" rel=\"nofollow\">NEAR Intents: Cross-Chain Fund Flow Investigation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.tokenpost.com\u002Fnews\u002Ftechnology\u002F26772\" rel=\"nofollow\">October 2: Recovery Announcement and Follow-Up Reporting\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Fol>","\u002Fmedia\u002Fscalebit\u002F2026\u002F10\u002F6b1b022207b53d63371b43ccf4de7f9a.png","2026-10-09T02:25:59Z","13 min read",true,"NEAR Intents Exploit Analysis: How 3.865M USDT Was Withdrawn Through Omni's Cross-Chain Infrastructure cover image",{"slug":19,"category":6,"categoryLabel":7,"subcategoryLabel":20,"authorName":9,"title":21,"excerpt":22,"contentHtml":23,"coverUrl":24,"publishedAt":25,"readTime":26,"cover":24,"hasCover":16,"coverAlt":27},"forced-transfer-is-not-a-backdoor-how-should-we-audit-legitimate-bypass-in-rwa-protocols-d1c885","Industry Research","Forced Transfer Is Not a Backdoor: How Should We Audit “Legitimate Bypass” in RWA Protocols?","In traditional crypto security reviews, seeing that an admin can move user funds is usually an immediate centralization red flag. In RWA systems, however, that conclusion does not always hold.","\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">In traditional crypto security reviews, seeing that an \u003Cstrong>admin can move user funds\u003C\u002Fstrong> is usually an immediate centralization red flag. In RWA systems, however, that conclusion does not always hold.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">ERC-7943 explicitly defines capabilities such as \u003Cstrong>forcedTransfer()\u003C\u002Fstrong>, \u003Cstrong>setFrozenTokens()\u003C\u002Fstrong>, \u003Cstrong>canSend()\u003C\u002Fstrong>, \u003Cstrong>canReceive()\u003C\u002Fstrong>, and \u003Cstrong>canTransfer()\u003C\u002Fstrong>. Freezing, forced transfer, and asset recovery are not necessarily hidden backdoors added by an implementation team; they may be explicit requirements of a regulated-token specification.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This is a class of RWA risk that ScaleBit believes deserves a different audit model. When an “exception” is part of the specification itself, the security question is no longer whether the exception exists. The real question is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If a privileged path is intentionally allowed to bypass certain rules, which invariants may legitimately diverge—and which invariants must remain non-bypassable?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">1. Forced Transfer Creates a Second Legitimate State Machine\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A conventional token transfer roughly follows one semantic path:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Holder Authorization → Transfer Conditions → Balance \u002F Ownership Transition\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">An RWA token may expose another equally legitimate path:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Privileged Authority → Enforcement Conditions → Balance \u002F Ownership Transition\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Both modify the same asset state, but they do not necessarily share the same preconditions.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Under some ERC-7943 permission models, for example, \u003Cstrong>forcedTransfer() \u003C\u002Fstrong>may legitimately bypass the normal \u003Cstrong>canTransfer() \u003C\u002Fstrong>path. But permission to bypass one transfer restriction does not imply that every other safety property may disappear with it.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A more useful review model is therefore to separate invariants into two categories:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"111111\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fdcb1b043cd8bb17a50493540a8389b51.jpg\" style=\"width: 414.6pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">An \u003Cstrong>onlyRole(AGENT) \u003C\u002Fstrong>check tells us who may enter the privileged path.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It does not tell us:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which security properties must still hold after that privileged state transition completes?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Privileged-path security is therefore not about eliminating semantic differences between normal and enforcement flows. It is about ensuring that:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Semantic divergence is strictly limited to what the specification actually requires.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">2. When frozen > balance Is Not an Accounting Bug\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">ERC-7943 contains a particularly counterintuitive state requirement: the frozen amount may exceed the account’s current balance.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A Solidity auditor may instinctively assume an invariant such as:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen(account) ≤ balanceOf(account)\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a regulated token, however, that assumption may be incorrect.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Suppose an address currently holds 10 tokens, but an enforcement authority intends to restrict not only the current balance, but also future assets received by that address.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If the system only allows:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">and the account later receives another 90 tokens:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>balance = 100\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen  = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">those additional 90 tokens may become transferable.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A valid enforcement state may therefore instead be:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>balance = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen  = 100\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Here, frozen no longer means merely:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">the portion of the current balance that is frozen.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It behaves more like:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>a policy constraint over both current and future asset state.\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">That distinction changes implementation-level security assumptions immediately.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For example:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"222222\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fb1d80f1cbc6a95042f39483b1e4fb03f.jpg\" style=\"width: 414.3pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">may underflow or revert whenever frozen > balance.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If permission-query functions are also expected to remain non-reverting under valid states, the implementation must explicitly handle this case, for example:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"图像2026-8-26 16.06\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F0833773e6ec6954e56d93466f4f27cde.jpg\" style=\"width: 414.9pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This illustrates an important RWA audit principle:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Do not infer invariants from variable names. Derive them from the state semantics defined by the specification.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The same rule applies to forced-transfer ordering.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If an ERC-721 or ERC-1155 enforcement path updates frozen accounting and also triggers a recipient callback, the relevant state should be reconciled before the external interaction. Otherwise, reentrancy may observe an intermediate state such as:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Ownership = New State\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Frozen Accounting = Old State\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The failure here is not excessive administrative power.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It is a violation of state consistency.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Authorization semantics may diverge. State-observation semantics still need to remain coherent.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Or more simply:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Bypass permission does not imply bypass ordering constraints.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">3. Revocability Propagates Through the Composability Graph\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Forced transfer is not only a property of the token contract itself. It also changes the assumptions made by every downstream protocol that integrates the asset.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Traditional DeFi frequently relies on an implicit assumption:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Assets held by a protocol can only leave through that protocol’s own state machine.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a revocable RWA, this assumption no longer necessarily holds.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Consider a vault holding $10 million of an RWA token. If the issuer or enforcement authority can alter the vault’s token balance outside the vault’s own logic, then even a perfectly implemented vault may experience:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"44444\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fdd3125cd0cf3468c7b224980c8c4a71c.jpg\" style=\"width: 415.2pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a bridge, the implication may be even more fundamental.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Suppose its backing invariant is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>Wrapped Supply ≤ Assets Locked in Custody\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If locked assets can leave custody through a privileged token-level path that the bridge does not control, then the bridge’s backing invariant now depends on issuer authority.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This leads to a broader security property:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>Revocability is a composability property.\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">When a protocol integrates a revocable asset, it inherits part of the issuer’s privileged state machine.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">That does not mean revocable RWAs are unsuitable for DeFi. It means integration reviews must ask additional questions:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Who can change protocol-held balances externally?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Does internal accounting observe those changes immediately?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Does the protocol assume custody = exclusive control?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which solvency or backing invariants depend on that assumption?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">From ScaleBit’s perspective, this is particularly important because the vulnerability may not exist in either contract independently. It may emerge from a composability assumption mismatch between the RWA token and the downstream protocol.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">4. Move From Privileged Roles to a Privileged Transition Matrix\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The previous analysis can be translated directly into a more practical review framework.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Instead of stopping at who holds AGENT_ROLE, whether that role is protected by a multisig, or whether the administrator is properly restricted, security reviews should compare the normal and enforcement paths explicitly.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A Privileged Transition Matrix can make those differences visible:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"55555\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F020ec4b0e64f840026ec32d0adadb41a.jpg\" style=\"width: 415.1pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The real objective is to distinguish:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Intentional Enforcement Semantics\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">from:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Accidental Security Bypass\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Implementation note: not every privileged action needs the same delay model\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Changes that modify the rules themselves—adding enforcement authorities, upgrading compliance modules, or expanding the scope of forced transfer—generally benefit from high-friction controls such as multisigs and timelocks.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Executing an already-defined emergency freeze may require faster action, because excessive delay can itself create an escape window.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A useful principle is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Changing authority should be slow; exercising existing authority can be fast only when the execution scope is tightly bounded.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Faster execution should therefore come with narrower limits around recipient, amount, asset, operator, and auditability.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">Conclusion\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">When the exception becomes the specification, the exception needs its own security semantics.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">One of the fundamental differences between RWA systems and traditional DeFi is that behaviors considered exceptional in permissionless tokens may be explicit protocol requirements in regulated assets.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">forcedTransfer() is not necessarily a backdoor.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">frozen > balance is not necessarily an accounting bug.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Bypassing holder authorization is not necessarily an authorization vulnerability.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The real failure occurs when:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A privileged path bypasses an invariant that the specification never intended it to bypass.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This is why ScaleBit believes RWA privilege reviews should not stop at:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Who has privilege?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">They should continue with:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">What semantics does that privilege create?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which invariants may diverge?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which invariants must survive?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which downstream protocols\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">silently assume they survive?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Once an exception path becomes part of the protocol specification, it can no longer be treated as a special admin function and reviewed in isolation.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It is a second asset state machine—and it should be audited as one.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For RWA security, the goal is not to eliminate privilege at all costs. It is to ensure that every privileged action has a clear, bounded, and verifiable semantic boundary.\u003C\u002Fspan>\u003C\u002Fp>","\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F379beee09c5161a2faf84aa2ca2a1f3b.jpg","2026-08-26T08:16:32Z","7 min read","Forced Transfer Is Not a Backdoor: How Should We Audit “Legitimate Bypass” in RWA Protocols? cover image",{"slug":29,"category":6,"categoryLabel":7,"subcategoryLabel":8,"authorName":30,"title":31,"excerpt":32,"contentHtml":33,"coverUrl":34,"seoTitle":31,"seoDescription":32,"seoImageUrl":34,"publishedAt":35,"readTime":26,"cover":34,"hasCover":16,"coverAlt":36},"bitslab-scalebit-security-team-discovers-a-zero-day-vulnerability-capable-of-transferring-all-assets-from-uniswap-wallet","ScaleBit","BitsLab's ScaleBit Security Team Discovers a Zero-Day Vulnerability Capable of Transferring All Assets from Uniswap Wallet","Recently, the ScaleBit security team under BitsLab identified a vulnerability in the iOS version of the Uniswap Wallet, which BitsLab has named the \"Unauthorized Access to Mnemonic Phrases\" vulnerability.","\u003Cp>In October 2024, the ScaleBit Security Team, part of BitsLab, identified a vulnerability in the Uniswap iOS wallet, which was named “Unauthorized Access to Mnemonic Phrases”. This flaw enables attackers with physical access to a device to bypass the wallet’s authentication mechanisms and directly retrieve mnemonic phrases stored on the device.\u003C\u002Fp>\n\u003Cp>This vulnerability implies that anyone with access to an unlocked device can extract the wallet’s mnemonic phrases in under three minutes. In everyday scenarios, temporarily lending a phone is not uncommon, especially among couples or friends. However, under the impact of this vulnerability, such seemingly innocuous actions could lead to the unintended exposure of wallet mnemonic phrases.\u003C\u002Fp>\n\u003Ch2 id=\"1-Background-Information\">1.Background Information\u003C\u002Fh2>\n\u003Cp>Mnemonic phrases are critical credentials in the blockchain ecosystem, enabling access to and management of on-chain assets. Their exposure can lead directly to the loss of user funds. The discovery of this vulnerability highlights significant security weaknesses in the user authentication processes and key storage mechanisms of certain wallets.\u003C\u002Fp>\n\u003Cp>It is worth noting that this vulnerability remains unaddressed in the latest version of the Uniswap Wallet available on the App Store (Version 1.42). We strongly advise all Uniswap Wallet users to remain vigilant and avoid lending their devices to others to prevent potential threats to their asset security. Additionally, users should closely monitor updates to the Uniswap Wallet and promptly install any patched versions.\u003C\u002Fp>\n\u003Cp>We deeply understand the potential security risks this issue poses to user assets. Since October of last year, we have repeatedly urged the Uniswap team to address the issue, but our concerns have not received the attention they deserve. Therefore, we have decided to publicly disclose this vulnerability to raise awareness among users and developers about its severity and to encourage stronger security practices.\u003C\u002Fp>\n\u003Cp>We firmly oppose any form of malicious exploitation and remain committed to providing professional security audits to safeguard the healthy development of the blockchain ecosystem.\u003C\u002Fp>\n\u003Ch2 id=\"2-Vulnerability-Analysis\">2.Vulnerability Analysis\u003C\u002Fh2>\n\u003Cp>2.1 In similar products such as Metamask and Unisat wallets, mnemonic phrases are typically encrypted using symmetric encryption algorithms like AES-256-CBC. However, in the authentication process of the Uniswap Wallet, likely aiming to enhance user experience, only FaceID verification is provided. Users can access the wallet, initiate transactions, or view mnemonic phrases after FaceID authentication, without being prompted to enter a password.\u003C\u002Fp>\n\u003Cp>This indicates that mnemonic phrases are either stored without encryption or encrypted using a fixed key. Upon reviewing the source code, it was confirmed that no effective encryption measures were applied during the storage of mnemonic phrases.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Fa1f64eb8de1f43673917fdb599f99158aa90ceb4\u002Fapps\u002Fmobile\u002Fios\u002FUniswap\u002FRNEthersRs\u002FRNEthersRS.swift#L119-L129\">https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Fa1f64eb8de1f43673917fdb599f99158aa90ceb4\u002Fapps\u002Fmobile\u002Fios\u002FUniswap\u002FRNEthersRs\u002FRNEthersRS.swift#L119-L129\u003C\u002Fa> \u003C\u002Fp>\n\u003Cp>In this implementation, mnemonic phrases are stored in the Keychain via the keychain.set method without any additional encryption measures. Although iOS Keychain provides certain underlying encryption and access control mechanisms, such as accessibleWhenUnlockedThisDeviceOnly, these protections primarily rely on system-level security features rather than application-level encryption. As a result, they are insufficient to fully ensure the security of mnemonic phrases.\u003C\u002Fp>\n\u003Cp>2.2 When users uninstall the wallet application directly, the mnemonic phrases stored on the device are neither deleted nor encrypted. However, the FaceID verification toggle within the wallet is reset, further compromising security.\u003C\u002Fp>\n\u003Cp>2.3 Uniswap Wallet supports encrypting mnemonic phrases and uploading them to iCloud, as well as recovering them from iCloud. Additionally, the app provides a recovery page. When in recovery mode, the application retrieves and displays a list of mnemonic phrases available for recovery.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Ff1dfab33d1e13f0b2c7790516b03620d703ddea5\u002Fapps\u002Fmobile\u002Fsrc\u002Fscreens\u002FAppLoadingScreen.tsx#L206\">https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Ff1dfab33d1e13f0b2c7790516b03620d703ddea5\u002Fapps\u002Fmobile\u002Fsrc\u002Fscreens\u002FAppLoadingScreen.tsx#L206\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>However, the conditions for triggering recovery mode are not limited to retrieving mnemonic phrases from iCloud. When the number of locally stored mnemonic phrases exceeds one, the recovery page is also displayed. In this scenario, the application may inadvertently expose multiple unencrypted mnemonic phrases.\u003C\u002Fp>\n\u003Cp>This design creates a convenient attack vector for malicious actors. However, even without recovery mode, the core issue of storing mnemonic phrases unencrypted remains. Attackers could leverage other methods to directly extract unencrypted mnemonic phrases stored on the device. Such methods typically require more advanced exploitation conditions, such as jailbreaking the device to gain full access to system files or sideloading a modified application.\u003C\u002Fp>\n\u003Cp>The unencrypted storage of mnemonic phrases thus serves as a critical entry point for potential attacks. Ensuring that mnemonic phrases are stored locally with robust encryption is essential to preventing the leakage of sensitive information.\u003C\u002Fp>\n\u003Ch2 id=\"3-PoC\">3.PoC\u003C\u002Fh2>\n\u003Cp>3.1 Install the Uniswap Wallet, Create a Wallet, Enable All Authentication Settings.\u003C\u002Fp>\n\u003Cp>Record the Wallet’s Mnemonic Phrase:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F9dd6a5757fa267c794f2e1721b4774a1.png\" alt=\"Figure1\" title=\"Figure1\">\u003C\u002Fp>\n\u003Cp>Enable All Authentication Settings:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F4b84d602b2b3ef88f9063b596a24c39b.png\" alt=\"Figure2\" title=\"Figure2\">\u003C\u002Fp>\n\u003Cp>3.2 Uninstall and Reinstall the Uniswap Wallet, Create a New Wallet.\u003C\u002Fp>\n\u003Cp>3.3 Uninstall the wallet once more and reinstall it.\u003C\u002Fp>\n\u003Cp>At this stage, the conditions to trigger the OnDeviceRecovery page are met, as the number of mnemonic phrases stored on the device exceeds one.\u003C\u002Fp>\n\u003Cp>Upon entering recovery mode, the wallet displays the Recovery Page, revealing all previously stored unencrypted mnemonic phrases from the device.\u003C\u002Fp>\n\u003Cp>This process exposes the user’s mnemonic phrases, demonstrating a significant design flaw in the Uniswap Wallet’s handling of mnemonic storage and recovery mechanisms.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fcc87cb78a2172fd35c31bc6873b28ee4.png\" alt=\"Figure3\" title=\"Figure3\">\u003C\u002Fp>\n\u003Cp>3.4 Verify one of the mnemonic phrases retrieved in recovery mode and confirm that it matches the mnemonic phrase created during the first wallet setup.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F835d31cdec72e7e706e4a6fa4ad7a565.png\" alt=\"Figure4\" title=\"Figure4\">\u003C\u002Fp>\n\u003Ch2 id=\"4-TimeLine\">4.TimeLine\u003C\u002Fh2>\n\u003Cp>The vulnerability was submitted via Cantina on October 21, 2024. On November 28, 2024, the project team responded that while exploiting the vulnerability requires physical access to an unlocked device, the Likelihood might be downgraded, but the Impact remains high. They stated plans to confirm the issue and propose a solution. On December 5, 2024, the project team further replied that this was a known issue and refused to offer any reward.\u003C\u002Fp>\n\u003Cp>The timeline is as follows:\u003C\u002Fp>\n\u003Cp>October 21, 2024: The vulnerability was submitted via Cantina.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fa51a1e26230beb21510984d8f4facf4f.png\" alt=\"Figure5\" title=\"Figure5\">\u003C\u002Fp>\n\u003Cp>November 28, 2024: The project team acknowledged the impact and planned to propose a solution.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fbbe16f778e76836ce801fd3a1ccb49ff.png\" alt=\"Figure6\" title=\"Figure6\">\u003C\u002Fp>\n\u003Cp>December 5, 2024: The project team stated that the vulnerability was already known and refused to provide a bounty.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F3e1d8566215a791fd61d068fd7ac0703.png\" alt=\"Figure7\" title=\"Figure7\">\u003C\u002Fp>\n\u003Cp>We reached out to the Uniswap team on December 18, 2024, and January 2, 2025, repeatedly urging them to address this issue promptly or disclose it to users. However, we received no response.\u003C\u002Fp>\n\u003Cp>We firmly believe that users have the right to be informed about potential security risks to their assets. Given that this vulnerability has remained unpatched and users are unaware of it, we have decided to disclose the issue publicly. We informed the Uniswap team of our disclosure plan one week ago.\u003C\u002Fp>\n\u003Ch2 id=\"5-5-Summary\">5.5.Summary\u003C\u002Fh2>\n\u003Cp>The root cause of this vulnerability lies in flawed design choices in the storage and access mechanisms for mnemonic phrases. The mnemonics are not effectively encrypted at the application layer, and the unreasonable conditions for triggering the recovery page allow attackers with physical access to a device to bypass the wallet’s authentication mechanism and directly retrieve the wallet’s mnemonic phrases.\u003C\u002Fp>\n\u003Cp>This vulnerability persists in the latest version of Uniswap Wallet (Version 1.42), posing a potential risk to all users of the wallet. Therefore, users must take extra precautions to secure their devices physically, avoid disclosing unlock passwords, and refrain from lending their devices to others.\u003C\u002Fp>\n\u003Cp>This incident also highlights the importance of prioritizing user asset security when designing wallet applications. Mnemonic phrases, as critical credentials for accessing and managing on-chain assets, must be adequately protected. Developers are advised to implement robust encryption at the application layer, such as encrypting mnemonic phrases using AES-256-CBC, and deriving encryption keys with user passwords via PBKDF2 or Argon2.\u003C\u002Fp>\n\u003Cp>At the same time, ordinary users should enhance their security awareness by properly safeguarding their mnemonics, choosing wallets that have undergone rigorous security audits, and ensuring that these wallets implement strong encryption and robust security mechanisms. Users should avoid using wallets with unverified or unknown security standards to manage their assets.\u003C\u002Fp>\n\u003Cp>Through this disclosure, we aim to raise awareness among developers and users about wallet security. Only through collaborative efforts—developers strengthening security designs, users improving security practices, and security teams contributing technical expertise—can we build a safer and more reliable blockchain ecosystem.\u003C\u002Fp>","\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fca78b6f0ba7830d01cb615ca07a9e9d5.png","2025-01-10T03:15:00Z","BitsLab's ScaleBit Security Team Discovers a Zero-Day Vulnerability Capable of Transferring All Assets from Uniswap Wallet cover image",1792060315528]