Hyperbridge Exploit Explained: How a Valid Proof Was Used to Mint $1B Fake DOT

Image generated by Gemini AI. Hyperbridge’s MMR Proof Relay Exploit.

This wasn’t a key hack or a smart contract bug — it was a failure to verify that a proof actually belonged to the message being executed.

Understanding Hyperbridge DOT Bridge Token Contract Exploit

One of the latest bridge exploit incidents in the news is Hyperbridge’s MMR proof replay exploit on April 13.

The attacker managed to gain authorization to mint nearly 1 billion bridged DOT tokens, which were sold into decentralized exchange pools, extracting around $237,000.

This exploit stands out because it did not occur due to:

• Validator key compromise
• A traditional smart contract vulnerability
Instead, it resulted from a flaw in Hyperbridge’s verification mechanism.

How the attacker tricked Hyperbridge

According to CertiK, the attacker:

• Sent a malicious cross-chain message to the Ethereum-side DOT bridge contract
• Attached a valid proof taken from previous _stateCommitments

Proof copied from State commitments from previous transaction. Certik

• Included a privileged instruction to change the admin of the DOT bridge contract

ChangeAdmin() Transaction request of attacker Certik.

Why the attacker’s transaction passed Hyperbrige’s Verification Test?

Hyperbridge verifies messages using Merkle proofs:

• Each transaction request → hashed into a leaf
• Leaves → combined into a Merkle tree
• Final hash → stored as the Merkle root

The contract correctly verified that:
✔ The proof was valid
✔ The proof connected to the stored Merkle root
✔ The proof corresponded to a valid leaf in that tree

What Hyperbridge’s verification process failed to verify

Hyperbridge’s verification Logic decoded. CertiK

However, the contract failed to verify that:

The proof corresponded to the specific transaction request being executed
In other words:

• The attacker submitted:

o A malicious request (changeAdmin)

o A valid proof from a different, legitimate message

• The system verified the proof

• But did not check whether:
hash(request) == leaf proven by the proof

Because of this missing binding:

• The proof was valid
• But it belonged to a different transaction

If Hyperbridge’s verification logic could verify that proof connected with a specific leaf hash – it would have identified that the proof sent did not correspond with the transaction request initiated by attacker.

Attacker gets authority to mint and burn Bridged Tokens!

Therefore – attacker’s message was validated as a valid transaction. When this was done, the admin of the DOT Bridge Contact was shifted to the address specified by the attacker.

New admin(attacker) for Polkadot Bridge contract Hyberbridge. Certik

The proof evaluated was of a legitimate transaction done by an authorised source who was permitted to change admin of Bridge Token Contract. However, Hyperbridge did not see that the proof was being reused for a different message sent by an attacker, who is not authorised to change admin of Bridge Token Contract.

Once admin of DOT Bridge contract was changed to attacker address – the attacker minted 1 Billion Bridged DOT Tokens and moved it selling it on DEX making $237,000.

The minted bridged DOT was 2800 times that of DOT’s circulating supply. DOT price in the pool crashed due to this transaction – with pools not having enough liquidity to absorb this transaction.

Losses and Recovery Updates

According to Hyperbridge -:

Losses caused due to this attack amount to more than $237,000 – which was the amount made by attacker selling those minted DOT tokens. The updated amount is $2.5M – caused due to impact on incentives provided by DOT pools across – Ethereum, Base, BNB Chain, and Arbitrum.