Home Web3 SecurityCrypto Hacks & Exploits Nomad Bridge Exploit – Aug 1, 2022 – Detailed Analysis

Nomad Bridge Exploit – Aug 1, 2022 – Detailed Analysis

by ImmuneBytes

Executive Summary

On August 1, 2022, the decentralized finance (DeFi) bridge known as “Nomad” suffered a massive exploit that resulted in a loss of over $190 million. This breach, which was executed by bypassing the message verification processes, resulted into massive draining of tokens from the bridge contract, which caused its Total Value Locked (TVL) to come down to just $1,794 from $190,740,000, in a matter of few hours.

The hacking frenzy was a collective effort from hundreds of wallets, which led to this catastrophic drop in the TVL. A total of 960 transactions with 1,175 individual withdrawals marked this exploit.

About Nomad Bridge

Nomad is a decentralized bridge protocol designed to facilitate secure cross-chain communication and asset transfers between different blockchain networks, including Ethereum, Moonbeam, Avalanche, Evmos, and Milkomeda. It operates under the premise of optimistic verification mechanisms, making it cost-effective and efficient for cross-chain applications.

The Exploit

The exploit was made possible due to a vulnerability in the initialization process of the Nomad protocol. Specifically, the “committedRoot” variable was set as an empty bytes32, which enabled attackers to pass unverified messages with zero content (32 zeros), avoiding the need to prove the deposit of tokens on a chain.

Nomad Bridge Address: https://moonscan.io/address/0xd3dfd3ede74e0dcebc1aa685e151332857efce2d

The Exploit Process

The attacker leveraged the vulnerability to directly call the “process()” function without undergoing proper verification (https://docs.nomad.xyz/the-nomad-protocol/verification-mechanisms/optimistic-verification). They manipulated the function to return true, allowing them to transfer an arbitrary amount of tokens out of the bridge.

Involvement of Multiple Actors

Notably, this hack involved multiple threat actors, including white hat hackers. At least 41 wallets participated in the exploit, which is considered a unique aspect of this attack. The ease with which attackers drained funds encouraged more participants.

Phishing Attempts

Another intriguing aspect was the presence of phishing attempts by a different malicious actor, who owned the ENS domain “nomadexploiter.eth.” This actor attempted to raise funds from white hat hackers, but Nomad confirmed on Twitter that they were not associated with this account.

Technical Analysis of the Exploit

Root Cause of Vulnerability

The root cause of the vulnerability lay in an implementation bug during a June 21 smart contract upgrade. This bug caused the Replica contract to fail in properly authenticating messages.

The Role of the Replica Contract

Nomad relies on the Replica contract for authentication of inbound messages. This contract tracks roots from other chains and ensures that messages are processed only after their optimistic timeout period has elapsed.

The Attack

Initial Suspicion

At 9:32 PM UTC, the initial dubious transactions caught attention:

A user executed a transfer of 0.01 WBTC (https://moonscan.io/tx/0xcca9299c739a1b538150af007a34aba516b6dade1965e80198be021e3166fe4c) through the Nomad bridge on MoonBeam.

Simultaneously, the user received a whopping 100 WBTC on Ethereum.(https://etherscan.io/tx/0xa5fe9d044e4f3e5aa5bc4c0709333cd2190cba0f4e7f16bcf73f49f83e4a5460)

This discrepancy might have been dismissed as a mere token decimal misconfiguration. However, a closer inspection revealed the transaction bypassed the usual verification, directly invoking the process() function. This raised two possibilities: a proof had either been verified in an earlier block, or an exploit was underway.

Message Processing

The attacker took advantage of the system by calling the process(byte memory _message) function, inputting a seemingly arbitrary _message.

Root Verification

Within the function, there’s an internal check acceptableRoot(messages[_messageHash]). This verification ensures the root has been previously submitted and waits until the optimistic timeout duration concludes. Interestingly, the default value for messages[_messageHash] is 0x00.

Bypassing Verification

The acceptableRoot(messages[_messageHash]) function, instead of serving its purpose, returned true, validating the message.

This anomaly was a consequence of the transaction initializing 0x00 as true when committedRoot was set to zero. This meant that the root of an unverified message would also be zero.

Having zero as a confirmed and valid root allowed the attacker to easily sidestep the intended verification.

Unrestricted Token Transfer

With the message falsely verified, the hacker gained the capability to transfer any desired token amount out of the bridge.

In-depth Analysis

Vulnerability in Message Authentication:
The core vulnerability lies in the message authentication mechanism. The Nomad system overlooked the validation step to confirm if a message had been previously approved before processing.

This malfunction was pinpointed to the acceptableRoot function within the Replica contract. Under normal circumstances, this function should confirm true only after the optimistic timeout period for a legitimate root ends. But, due to an initialization glitch, the function consistently confirmed true for specific Replica contracts.

Code Exploit

Whenever the system received a message, it fetched the root from a mapping and then cross-referenced it with the acceptableRoot function.

The compromised function’s code is as follows:

For messages that were either unregistered or forged, the _root would default to bytes32(0). In any Replica that initiated with _committedRoot as bytes32(0), the confirmAt[bytes32(0)] was preset to 1.

Simplified Exploitation

The simplicity of this exploit was quite unsettling. In essence, any user could emulate the original hacker’s transaction calldata. They just had to swap the original address with their own and execute the transaction. The entire maneuver was essentially a straightforward copy-paste action.

Impact and Implications

Losses Incurred

The Nomad hack resulted in a staggering loss of over $190 million, which had a significant impact on the bridge’s users and the DeFi community at large.

Contagion Effect on Other Chains

The hack’s impact extended to other chains that relied on Nomad to mint-wrapped tokens. These chains experienced a decline in TVL due to the loss of funds on the Nomad bridge.

Impacted Tokens and Protocols

Tokens such as DAI, USDC, USDT, and AAVE suffered from volatility due to the hack, impacting token holders. Lending and DEX protocols on affected chains also experienced a reduction in TVL.

Arbitrage Opportunities

The exploit created arbitrage opportunities as the price of wrapped tokens on affected chains diverged from their actual values. Users took advantage of this situation, further complicating the aftermath.

Response and Recovery

Nomad’s Initial Response

Nomad’s co-founder, Pranay Mohan, expressed his distress over the hack and announced efforts to recover the stolen funds and devise a plan to reboot the Nomad bridge.

Return of Funds by Whitehat Hackers

As of August 15, 2022, over $33 million had been returned to Nomad’s wallet by white hat hackers, demonstrating the community’s willingness to help mitigate the damage.


The Nomad bridge hack of August 1, 2022, was a significant event in the DeFi space, resulting in substantial losses. The vulnerability’s exploitation revealed weaknesses in cross-chain bridge protocols and their susceptibility to attacks.

This incident highlights the importance of security in cross-chain bridges and the potential for contagion effects when such bridges are exploited. It serves as a reminder for the DeFi community to prioritize robust security measures and continuous auditing to safeguard users’ assets in an increasingly interconnected blockchain ecosystem.

You may also like