The Wormhole Bridge Hack: Anatomy of a 320 Million Dollar Loss

320 million dollars stolen. Signature verification bypassed. Jump Crypto refilled an equivalent amount within 24 hours.

That’s the three-sentence skeleton of the Wormhole bridge hack on February 2, 2022. It wasn’t the biggest single loss of that year — Ronin’s 625 million came later — but it became the rare big bridge attack with no real loss to end users. Not because Wormhole was sturdy, but because Jump Crypto extremely quickly plugged the hole out of its own pocket.

This piece walks the timeline: what Wormhole is, where the bug actually lived, how the exploit ran, why Jump took the loss, and what the industry inherited from it.

What Wormhole does

Wormhole connects Solana to a number of EVM chains (Ethereum, BSC, Polygon, Avalanche). The most common use is: you lock 1 ETH on Ethereum, Wormhole mints 1 wETH on Solana, and vice versa. Underneath, the design is a matched pair of receipts on the two chains, with the bridge’s contract and validators keeping the totals in sync.

Wormhole’s validator set is called the Guardian Network — at the time, 19 independent node operators, with 13 of 19 signatures required for any cross-chain message. Guardians witness a deposit on Ethereum, sign it, and the signatures get bundled into a VAA (Verified Action Approval) that the Solana-side bridge contract then verifies before minting wETH.

Structurally this matches the CEX vs DEX framing: you’re trusting a specific set of validators to sign honestly and a specific contract to verify strictly. Either step breaks and the bridge breaks. Wormhole’s failure was the second one.

(/uploads/20260529/1780055382673-46303.png)

The bug: a “looks-like” check instead of a “is-it” check

The Solana-side contract used a verify_signatures step that depended on Solana’s Secp256k1 system instruction to perform signature verification. The flaw was that the contract never actually checked whether the caller had invoked the genuine Secp256k1 system instruction.

The intent was: “I let Solana verify signatures; only if it verified do I proceed.” What got shipped was: “I see an instruction labeled Secp256k1, so I’ll trust it.” All the attacker needed was to craft a fake instruction with a matching label and the contract assumed the verification had happened. This class of bug — “signature verification bypass” — went straight onto the must-check list for Solana program audits after the incident: it passes unit tests because under normal calls the logic looks correct, and only a malicious crafted instruction exposes it.

This is the classic “syntactic vs semantic verification” split. The code trusted a label without demanding it come from a trusted source. The attacker could submit a “VAA” the Guardians had never actually signed, and the bridge minted anyway.

It’s worth contrasting with Ronin: Ronin lost because validator keys were phished, the “people” of the multisig were compromised. Wormhole lost because the contract itself failed to verify signatures, the “mechanism” of the multisig was bypassed. Both end in the same sentence from the Ronin post-mortem: a bridge’s safety equals the weakest verification step inside it.

How the attack unfolded

On chain the trail looked roughly like this:

First, the attacker locked nothing on Ethereum. There was no real ETH collateral; the target was to mint wETH on Solana out of thin air.

Second, a forged instruction call. The attacker stuffed a transaction containing a fake instruction shaped like the Secp256k1 verification and passed it to Wormhole’s bridge program.

Third, the bridge contract believed the signatures had been checked and minted 120,000 wETH — with zero matching collateral on Ethereum. At the ETH price of the day that came to about 325 million dollars.

Fourth, moving and swapping. Part of the minted wETH stayed in the Solana ecosystem; part was reverse-bridged to Ethereum to swap back into real ETH and USDC.

From the first suspicious transaction to the bridge being noticed took only a few hours. Compared with Ronin’s six-day delay, this fast detection was the key window for the rapid bailout that followed.

The 24-hour rescue and the aftermath

Wormhole’s main backer is Jump Crypto, the crypto arm of the quantitative trading giant Jump Trading. Inside 24 hours, Jump publicly announced it would inject 120,000 ETH from its own treasury to restore full collateralization of Solana-side wETH. For ordinary users this meant: real ETH could still be redeemed; protocols holding wETH didn’t get hit by cascading liquidations.

Why was Jump willing to absorb it? Wormhole was Jump’s flagship infrastructure, and Solana’s ecosystem was on an upswing at the time. Bridge failure would have collapsed the credit of the whole stack — Jump’s other Solana exposure was worth far more than 320 million dollars to protect. The “zero user loss” story also had enormous PR value for an institution building a long-term presence in crypto.

The Wormhole team simultaneously paused the bridge, patched the contract (the Solana side now verifies that Secp256k1 actually comes from the real system program), published the full post-mortem and audit, and raised the Immunefi bounty cap to 10 million dollars. Together with the DAO hack and the Ronin hack, these form the three most cited case studies in the literature on bridge safety.

(/uploads/20260529/1780055410905-75773.png)

What an ordinary user should take away

First, a bridge isn’t “automatic” — its safety equals the engineering quality and the rescue willingness of the team behind it. Wormhole’s ability to “hide the loss” from users was a Jump decision, not a property of the bridge. The next bridge may not have a backer with that much skin or that much intent.

Second, wrapped tokens on the far side of a bridge always carry the bridge’s credit risk. Even if the underlying asset on the origin chain is fine, the wrapped version can be inflated, depegged, or devalued, and your “receipt” loses value instantly. Structurally this is the same family of risk as stablecoin risk — you’re trusting the issuer, not the asset.

Third, treat any cross-chain move quantitatively. Frame “I’ll bridge 1 ETH to Solana to play around” as “I’m lending 1 ETH to the bridge’s validator team and hoping they return it honestly.” Under that mindset, only bridge what you’ll actively use, and never park large balances long-term in wrapped tokens. The reasoning matches choosing an exchange.

A bridge’s safety equals the safety of the weakest chain it connects

Worth keeping for the long run: a bridge doesn’t make two chains safer together; it pulls their joint safety floor down to the same low point. Wormhole wasn’t a Solana problem, wasn’t an Ethereum problem — it was a bridge problem. Under two hundred lines of mis-written verification turned a 13-of-19 multisig into 0-of-19.

Next time you see a new chain advertise “we’ve established cross-chain interoperability with the major ecosystems,” add one more question: who built that bridge, who verifies it, and who eats the loss when it fails. If the answer isn’t clear, leaving assets on whichever chain you actually know and accept is always the more conservative — and the smarter — choice.