Hyperbridge incident analysis

On April 13, 2026, Hyperbridge was exploited through a vulnerability on the custom logic, resulting in the loss of approximately $242,000. Let’s take a closer look at how the attack was carried out.

Original Attacker: https://etherscan.io/address/0xc513e4f5d7a93a1dd5b7c4d9f6cc2f52d2f1f8e7

Vulnerable Contract: https://etherscan.io/address/0x6c84edd2a018b1fe2fc93a56066b5c60da4e6d64

Attack Tx: https://etherscan.io/tx/0xb93aab835e4002f7d46b63e37a156c78abd1d9256df094d63321deeb514a0634

https://etherscan.io/tx/0x6f1efcde4a52db999c8cd233364d889292ae5ba357d9f2ead3dd3774010a0808

https://etherscan.io/tx/0x743f4bdb67df7e6db57346e557f94ded8d7f85e854040963b7f345545e227125

https://etherscan.io/tx/0xb80c7d4cde034689eb9aa42f0d28aa01d12e233e3805a7c8888ed871b7443c3a

https://etherscan.io/tx/0xb28ab9526e1538bdb7a26ec8485d055f9e417620c72a2f4de0f42234b5f8ac09

https://etherscan.io/tx/0x240aeb9a8b2aabf64ed8e1e480d3e7be140cf530dc1e5606cb16671029401109

https://etherscan.io/tx/0xfa23fb22cc8ff10518e561817dea838d3232f7573fd90bd81fd7a30a9161b6f6

Analysis

The vulnerable contract was HandlerV1.sol, specifically the handlePostRequests() function, which is responsible for verifying incoming cross-chain requests using Merkle Mountain Range (MMR) proofs before dispatching them for execution. Its purpose is simple: verify that a request truly existed on the source chain, then safely execute it on the destination chain.

The problem starts with how the function accepts user input. When a relayer calls handlePostRequests(), they provide two important pieces of data: request.proof, which is the MMR proof, and request.requests[], which contains the actual request payloads. Each PostRequestLeaf includes leaf.request, leaf.kIndex, and leaf.index. The dangerous part is that leaf.request contains the real business logic - destination address, calldata, timeout, source chain, and all execution details - and all of this is fully controlled by the relayer.

Instead of reconstructing the original request from the cryptographic proof, the contract directly trusts the relayer’s submitted payload. It computes the commitment using:

This means the contract is hashing attacker-controlled input. In other words, the commitment being verified is not extracted from proof data, but generated from whatever payload the attacker chooses to submit. This is the fundamental security mistake.

However, MMR verification only proves one thing: whether that leaf hash belongs to the trusted MMR root. It does not verify what function is being called, whether the payload was modified, or whether the request matches the original approved message from the source chain. It only proves that a hash exists somewhere inside the root.

This creates a dangerous gap between what is verified and what is executed. The contract verifies the existence of a hash, but after verification succeeds, it directly executes:

This means the protocol executes leaf.request, which is raw attacker-controlled calldata, instead of reconstructing and executing the canonical request proven by the MMR proof.

The attacker leveraged this pattern to invoke handlePostRequests(), minting a quantity of DOT, and subsequently swapping it for ETH valued at approximately $242K.

Conclusion

In conclusion, the Hyperbridge exploit was not caused by broken Merkle proofs, flawed MMR libraries, or cryptographic failure. It was caused by a verification logic flaw where the protocol proved that a hash existed, but executed whatever the attacker supplied. In bridge security, verifying a hash is not the same as verifying intent. That single mistake was enough to let the attacker take over the bridged DOT token and mint assets out of thin air.