Wormhole incident, 2022-02-02

Wormhole's guardians sign messages (VAAs) that the destination contract must verify. On Solana, signature checks are done by a native program, and a contract proves that check happened by reading the special "instructions sysvar" account. Wormhole's verify_signatures used a deprecated helper that loaded the instruction data from whatever account was passed in, without confirming that the account really was the sysvar. The attacker passed an account they had crafted to look like a successful signature check, so the contract recorded guardian approval that never occurred, and the forged VAA minted 120,000 wETH (CertiK; Kudelski Security).

The guardian set itself — 19 independent operators — was never compromised. That is the key distinction: a strong validator set gives no protection if the on-chain code that checks their signatures can be tricked.

Recovery was not a protocol feature; it came from a well-funded backer choosing to absorb the loss.

The attack also shows why non-EVM code needs its own review. Solana's account model passes every account a program reads as an explicit input, so a program must check each account's identity itself; EVM developers used to implicit context can easily miss that. Bridges that span different virtual machines double the surface where such assumptions can break.

At the time

Holders of Wormhole wETH on Solana faced a possible depeg until Jump's replenishment was announced. The cautious step was not to sell wETH at a discount in the first hours, and not to bridge new funds until Wormhole confirmed the patch and the backing.

Now

Wormhole messages now need 13 of 19 guardian signatures (L2Beat), and the network is used by bridges such as Mayan. When a bridge relies on an external messaging layer, its risk card should show both layers; ours does. Check that a bridge's contracts are verified and that it publishes audits for chain-specific code, especially on non-EVM chains.