Wormhole — Solana bridge exploit

What happened

On 2 February 2022, an attacker exploited a critical flaw in the Wormhole cross-chain bridge and minted 120,000 wrapped Ether (wETH) on the Solana blockchain without depositing any corresponding ETH on Ethereum. The attacker then swapped 93,750 of those tokens for SOL and other assets across a series of transactions, converting unbacked synthetic coins into real tradeable assets. Total losses reached approximately $325 million, making it the second-largest DeFi exploit at the time and the largest single exploit not subsequently returned.

Jump Crypto, the quantitative trading firm and parent company of Wormhole’s developer Certus One, replenished the bridge within 24 hours by depositing 120,000 ETH from its own balance sheet. This prevented any user-facing loss but represented a direct $325 million outlay by Jump. The bridge was taken offline, patched, and relaunched within a week. The attacker has not been publicly identified and the stolen funds, while trackable on-chain, have not been recovered.

How it worked

Wormhole is a message-passing bridge: rather than moving assets directly, it passes cryptographically signed messages between chains. When a user deposits ETH on Ethereum, Wormhole’s nineteen guardian nodes each observe the deposit and sign a “VAA” — a Verified Action Approval — attesting that the deposit occurred. The bridge on the receiving chain accepts the transfer only when it verifies a quorum of genuine guardian signatures.

The vulnerability was in the Solana-side contract’s signature-verification logic. Specifically, a helper function called verify_signatures was designed to check that the guardian signatures were legitimately produced by the expected guardian accounts. The Solana runtime provides a system call — secp256k1_program — that can verify Ethereum-format signatures. The Wormhole contract was supposed to call this system program to validate each guardian signature.

The flaw: the contract checked that secp256k1_program had been invoked somewhere in the transaction, but did not verify it had been invoked with the correct inputs for the specific message being validated. An attacker could craft a transaction that included a trivial, valid call to secp256k1_program on unrelated data — satisfying the “was this program called?” check — while passing fabricated signature data for the actual VAA. The bridge then accepted the fabricated VAA as validly signed by the guardian set and minted the requested 120,000 wETH.

In practical terms: the contract was checking that an identity check had been performed somewhere, rather than checking that the identity check had been performed on the thing that mattered. This is a class of vulnerability sometimes described as “confused deputy” — a privileged subsystem (the signature verifier) is invoked in a way that satisfies a surface-level requirement without actually performing its intended function.

A GitHub commit three days before the exploit had introduced a partial fix for a related issue, but the corrected code had not been deployed to production. The attacker appears to have identified the vulnerability by monitoring the repository’s commit history — the patch was visible in the repo before it was live on-chain.

Timeline

• 30 January 2022 — A commit is pushed to the Wormhole GitHub repository addressing a related signature-validation issue. The fix is not deployed.
• 2 February 2022, approximately 18:00 UTC — The attacker submits the first exploit transaction. 120,000 wETH is minted on Solana.
• 2 February 2022, ~20:00 UTC — The attacker converts approximately 93,750 wETH to SOL and other assets.
• 2 February 2022, ~21:00 UTC — Wormhole detects anomalous activity and takes the bridge offline.
• 3 February 2022 — Jump Crypto deposits 120,000 ETH to recapitalise the bridge. Wormhole publishes an incident statement. On-chain messages are sent to the attacker’s address offering a $10 million white-hat bug bounty for return of funds.
• 7 February 2022 — Wormhole relaunches with patched contracts after a third-party security review.
• No funds returned — The attacker does not respond to the bounty offer. Stolen assets remain in attacker-controlled wallets; portions have been mixed and bridged to other networks.

What defenders should learn

The root cause here is an incomplete validation check: the contract confirmed that a verification step had been triggered somewhere in a transaction, rather than confirming it had been triggered correctly on the specific data requiring verification. This is a subtle but catastrophic distinction. Any smart contract that relies on a privileged external program or system call must verify not just that the call was made, but that it was made with the correct inputs and produced the expected output for the specific context at hand.

The patch-to-production gap is a separate and equally important failure. The fix was in the public repository for three days before the exploit occurred. An attacker monitoring commit activity on a protocol holding hundreds of millions of dollars has strong financial incentive to examine every change. Protocols that deploy fixes without immediately going live create a window in which the vulnerability is known — from the commit diff — but unpatched. The correct operational posture is to treat any security-relevant patch as requiring emergency deployment, not standard release cycle scheduling.

Cross-chain bridges are structurally among the most complex and highest-value attack surfaces in DeFi. Every bridge encodes assumptions about the trust model between chains — who can authorise a transfer, how that authorisation is verified, and what happens if the verification logic has a bug. The attack surface is amplified by the fact that bridges typically hold assets from both connected chains simultaneously, meaning a single flaw can empty both sides at once. Bridges that hold significant value should undergo continuous adversarial review, not point-in-time audits, with monitoring systems specifically tuned to detect unexpected minting events on either chain.