On 2 February 2022 an attacker minted 120,000 wrapped ETH on the Wormhole bridge by supplying a fake system account to a signature check. The code verified a signature against an account it never confirmed was genuine. The lesson applies to any code that validates data using inputs the caller controls.
What the sources say happened
CertiK's incident analysis describes an exploit on the Solana side of the bridge at around 5:58 PM UTC on 2 February 2022. The verification step used a deprecated function that did not check whether the supplied system account was the real one. The attacker injected a spoofed account, the check passed, and the attacker then posted a forged message and called the function that mints wrapped tokens.
The write-up values the stolen tokens at over 320 million dollars at the time and calls it the second largest DeFi theft up to then. It also lists asset figures that are not fully consistent with that headline, so use the amount as approximate.
The response
Wormhole acknowledged the exploit the same day. On 3 February, Jump Trading, described as Wormhole's parent company, said it supplied Ether to replace the stolen funds after a bounty offer of roughly 10 million dollars was ignored. Solana published a post-mortem on 8 February. I did not retrieve that post-mortem, so details beyond its date are not covered here.
The general bug class
Strip away the chain specifics and this is an input validation failure. A function accepted an account from the caller and trusted it because it had the right shape. Nothing proved it was the account the protocol meant.
Familiar versions appear everywhere:
- A webhook handler that trusts a signature header without checking the signing key's origin.
- A service that accepts a JWT but does not pin the issuer or audience.
- A build step that verifies a checksum fetched from the same place as the file.
The OWASP Smart Contract Top 10 for 2025 lists input validation and access control as separate entries for this reason. Both are about deciding what a caller is allowed to supply.
Review questions for verification code
- Which inputs to this check can the caller choose?
- Is each one compared to a fixed, known value, not merely validated for format?
- Are deprecated verification helpers still in use, and does the changelog say why they were deprecated?
- Does a negative test pass a look-alike input and expect rejection?
- Is there a cap or rate limit on what a single message can mint or release?
That last item matters because a bridge is a high-value target. Limits on a single action do not stop a bug, but they shrink the loss while you respond.
Quick check
Was the signature itself forged?
According to the incident analysis, the weakness was in verifying which account supplied the data. The attacker spoofed the account the check relied on, so the check passed.
Who covered the loss?
CertiK reports that Jump Trading said on 3 February it supplied Ether to replace the stolen funds.
Sources
Last reviewed: 19 October 2026.
