Back to Blog

Revisiting the Wormhole Attacks

Code Auditing
March 22, 2022

1. Background

Wormhole, which is also known as Einstein-Rosen bridge, is a speculative structure linking disparate points in space-time. In the world of blockchain, wormhole is used as the bridge between different chains (e.g., Solana and Ethereum. Users can transfer the tokenized assets across blockchains with wormhole.

On Februrary 2nd, 2022, Wormhole was hacked and the attacker managed to mint 120,000 wrapped Ether worth of $320 million, which is the second-largest loss after Poly Network in DeFi history.

2. How Wormhole works

Wormhole works by monitoring the messages emitted on each chain. The monitored message will be forwarded to the target chain so that a cross-chain communication protocol can be built.

The intuitive question is how to guarantee that the monitored message is trust. To solve this problem, Wormhole introduces 19 extra nodes, which are called guardians. The current guardian set can be checked in Wormhole Explorer. Each guardian can verify the monitored message independently and sign on message.

In Wormhole, the message is organized in VAA format. The VAA consists of two parts. One is the header, which collects the signatures from the guardians. The other one is the body, which contains the information for target chain, message payload, etc.

Once the sigantures from the guardians reach a consensus threshold, the VAA can be posted on chain.

In summary, guardians are responsible for the integrity of the transferred message.

3. Token Bridge

After introducing how the message is transferred between different chains, it will not be difficult to understand how the Token bridge, which is the main applications in wormhole, works.

To transfer tokens from chain A to chain B. Wormhole locks the tokens on A and mint them on B. This is the high level idea. In practical, this can be split into three steps. First, the tokens on chain A is locked. Second, the message that the tokens on chain A should be transferred into chain B is broadcasted. Third, chain B receives the message, the corresponding tokens are minted. Everything is done.

4. Solana Instructions

In Solana, a transaction consists of multiple instructions. Each instruction contains a program ID, accounts, and the data. The program ID represents the program (a smart contract) that will handle the instruction. The program will interpret the data and operates on the provided accounts.

5. The Wormhole Attack

In short, the attacker minted 120,000 ETH on Solana without locking any assets on Ethereum. The transaction is here.

Thus, the question is how the attacker is able to mint the 120,000 ETH on Solana. Let’s detail the steps. To mint the Token, instruction complete_wrapped is invoked. This instruction receives several addresses, and the third one is the address storing the signed message. Before minting the 120,000 ETH, the chain B (i.e., Solana) should receive the signed message (i.e., VAA) indicating that 120,000 ETH was locked in chain A (i.e., Ethereum).

To post the message, post_vaa defined in post_vaa.rs is invoked. Consequently, an account will be created for storing the message. However, post_vaa does not check the signatures from guardians. Instead, verify_signaures defined in veryify_signatures.rs verifies the signatures.

The fourth account fed to verify_signatures is the system instruction account. Now let's explore how verify_signatures works.

At line 103, function load_instruction_at is invoked to load the previous executed instruction secp_ix. secp_ix will invoke the Secp256k1 signature verification function. Thus, the verify_signatures verify the signatures by checking the previous executed instruction secp_ix. Now did you figure out everything? Function load_instruction_at does not check where to load the instructions !!! You are expected to load the instruction from Sysvar:Instructions.

However, the fourth account of the attack transaction is 2tHS1cXX2h1KBEaadprqELJ6sV9wLoaSdX68FqsrrZRd rather than Sysvar:Instructions. In this case, the attacker successfully bypass the signature verification process. The wormhole thought the verification is passed and the message is posted to the chain, resulting in 120K ETH minted without locking anything!

Let’s look at a legal verification instruction. This transaction consists of two instructions. The first one invokes the Secp256k1 verification function while the second one invokes verify_signatures instruction. Note the fourth account here is Sysvar:Instructions.

After minting the 120K ETH, the attacker is able to withdraw it back to Ethereum and change it into the other tokens to get the profit.

6. Patch

As mentioned in the repo, since version 1.8.0, load_instruction_at is not safe and the Sysvar accounts address is not checked. Instead, load_instruction_at_checked is recommended.

7. Our Thought

  • Developers should be very familiar with the external functions they used.
  • Keep focusing on any important changes of the used libraries. If the library changes, the code using the library may need to be changed.
  • The library maintainer should be aware the potential risks for specified changes and notify the whole community in time. Simply adding annotations may not work and is not enough.
  • Your contract code needs to be audited if the versions of the library and the code are changed.

About BlockSec

BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world in order to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaSuites extension for web3 builders surfing efficiently in the crypto world.

To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.

Official website: https://blocksec.com/

Official Twitter account: https://twitter.com/BlockSecTeam

Sign up for the latest updates
~$5.57M Lost: X100 Freezer, NEM Exploits | BlockSec Weekly
Security Insights

~$5.57M Lost: X100 Freezer, NEM Exploits | BlockSec Weekly

This weekly report covers two security incidents on Ethereum and BNB Chain from October 19 to October 25, 2026. It examines a flash-loan-funded governance takeover of X100 Freezer and a tax-settlement flaw affecting a NEM token liquidity pool on BNB Chain. Estimated losses within the report's scope total approximately $5.57M: ~$4.75M from the representative X100 transaction and ~$820K from the NEM pool incident. The total excludes separately reported follow-on X100 extractions.

~$3.87M Lost: Autheo Network, UNCX Hacks | BlockSec Weekly
Security Insights

~$3.87M Lost: Autheo Network, UNCX Hacks | BlockSec Weekly

This weekly report covers 3 security incidents from October 12 to October 18, 2026, with approximately $3.87M in total estimated losses. Autheo Network suffered a ~$1.76M private key compromise, Qubic Wallet lost ~$1.30M due to weak seed generation, and UNCX Network's Smart Token Vesting V2 contracts suffered an ~$807K accounting error across Ethereum, BNB Chain, Base, and Robinhood Chain. The highlighted UNCX analysis explains how a flawed aggregate share calculation mixed vesting tranches created at different token-to-share ratios and enabled excess withdrawals from shared pools.

~$542K Lost: MakerDaoBot Exploit | BlockSec Weekly
Security Insights

~$542K Lost: MakerDaoBot Exploit | BlockSec Weekly

This report covers 1 security incident on Ethereum from 2026/10/05 - 2026/10/11, with an estimated loss of approximately $542K. An attack contract deployed a malicious adapter and passed it to a MakerDaoBot function that lacked access control, causing the bot to grant the adapter permission over its internal MakerDAO balances. The adapter settled four legacy ETH-A auctions and converted 200 units of ETH-A collateral to WETH; the attack contract unwrapped it and sent 200 ETH to the attacker.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit
Revisiting the Wormhole Attacks