Cowrie Research

hyperbridge-token-gateway-mmr-proof-forgery-admin-takeover-dot-mint-2026-04-13

16 min read

Hyperbridge Token Gateway MMR Proof Forgery / Forged ChangeAssetAdmin DOT Mint (2026-04-13)

  • Name: Hyperbridge Token Gateway MMR proof forgery / forged ChangeAssetAdmin DOT mint
  • Date: 2026-04-13
  • Protocol: Hyperbridge Token Gateway
  • Chain: Polkadot + Ethereum + Base + BNB Chain + Arbitrum
  • Category: bridge verification failure / Merkle Mountain Range proof forgery / verifier input-validation failure / forged admin-message acceptance / unbacked wrapped-asset mint
  • Loss: initially disclosed around $237K, later revised by Hyperbridge to roughly $2.5M across Ethereum, Base, BNB Chain, and Arbitrum after including a smaller first extraction phase and losses from associated incentive pools
  • Summary: Hyperbridge’s Token Gateway treated a Hyperbridge-proven message as authentic if HandlerV1.handlePostRequests() could recompute the expected overlayRoot from a supplied Merkle Mountain Range proof. On 2026-04-13, the attacker exploited a missing bounds check in the underlying MerkleMountainRange.VerifyProof() path: leaf_index was not constrained to be < leafCount. By submitting leafCount = 1 and leaf_index = 1, the attacker forced CalculateRoot() down a branch where the forged leaf was never incorporated and the function simply returned proof[0]. Because the attacker set proof[0] equal to the trusted historical root, Hyperbridge accepted a fabricated ChangeAssetAdmin message, transferred admin and minter rights on bridged DOT to attacker-controlled code, and let the attacker mint 1,000,000,000 unbacked DOT for liquidation against real pool liquidity.
  • Trigger / entry point:
    • Hyperbridge’s EVM-side HandlerV1.handlePostRequests() built MmrLeaf objects directly from user-supplied leaf.index values and passed them into MerkleMountainRange.VerifyProof().
    • The handler validated destination, timeout, and duplicate-message state, but did not validate leaf.index < request.proof.leafCount before handing execution to the proof library.
    • In the MMR library, CalculateRoot() had a special-case return for leafCount == 1 && leaves.length == 1 && leaves[0].leaf_index == 0; out-of-bounds leaf_index = 1 skipped that path and reached a generic branch that could return attacker-controlled proof data instead.
    • The forged message used that verifier gap to submit a fake ChangeAssetAdmin request against the bridged DOT token path.
  • Root cause:
    • The bridge’s authenticity boundary failed inside its proof verifier, not in signer custody or relayer honesty.
    • HandlerV1 treated untrusted request proof metadata as already well-formed and never enforced the basic invariant that a proven leaf index must lie inside the claimed tree size.
    • MerkleMountainRange.CalculateRoot() then behaved inconsistently across the leafCount == 1 edge case: valid leaf_index == 0 returned the leaf hash, while invalid leaf_index == 1 could bypass leaf incorporation entirely and return proof[0] as the computed root.
    • That decoupled the message commitment being authenticated from the root being checked, so Hyperbridge accepted a message the source side had never committed.
  • Exploit path:
    1. The attacker prepared contracts on Ethereum, including a pre-deployed contract that would receive admin rights, mint bridged DOT, and route the dump through available liquidity.
    2. In exploit transaction 0x240aeb9a8b2aabf64ed8e1e480d3e7be140cf530dc1e5606cb16671029401109, they called the EVM-side Hyperbridge handler with a forged post-request batch containing a ChangeAssetAdmin action targeting the bridged DOT token path.
    3. The submitted proof claimed a single-leaf MMR with leafCount = 1, but the attacker supplied leaf_index = 1 instead of 0 and set proof[0] equal to the trusted overlayRoot already stored onchain.
    4. Because no bounds check rejected the out-of-range leaf index, HandlerV1 forwarded the forged data into MerkleMountainRange.VerifyProof().
    5. In CalculateRoot(), the invalid leaf index skipped the leaf_index == 0 fast path; getSubtreeLeaves() found no in-range leaves for the claimed subtree, so the function pushed proof[0] directly into peakRoots and ultimately returned that attacker-chosen value as the computed root.
    6. Since the attacker had set proof[0] equal to the trusted historical root, verification passed even though the forged request commitment had never been part of that tree.
    7. HandlerV1 then dispatched the fabricated incoming message, which caused TokenGateway at 0xFd413e3AFe560182C4471F4d143A96d3e259B6dE to grant admin and minter rights on bridged DOT token 0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8 to attacker-controlled code.
    8. With mint authority in hand, the attacker minted 1,000,000,000 bridged DOT and dumped it into available DEX liquidity. Hyperbridge later said the same underlying verifier issue also powered an earlier smaller extraction and losses across Ethereum, Base, BNB Chain, and Arbitrum.
  • What the attacker needed to be true:
    • Hyperbridge needed to trust EVM-side proof verification as sufficient authority for incoming admin-changing messages.
    • HandlerV1 needed to pass attacker-controlled leaf.index and leafCount through without enforcing leaf_index < leafCount.
    • The MMR library needed to preserve the edge-case behavior where an invalid single-leaf index could make the computed root collapse to proof[0] instead of the actual leaf hash.
    • The destination-side DOT token and connected pools needed enough live mint authority and liquidity to convert the forged message into realizable value before the bridge pause.
  • Technical anatomy worth remembering:
    • This was a proof-verifier implementation failure, not a signer compromise and not a relayer fraud story. Hyperbridge’s core promise was cryptographic proofs, not human committees; the failure still occurred because one verifier edge case let attacker-supplied calldata mint fake authenticity.
    • The decisive invariant was not merely root matches. It was the root must have been recomputed from the actual message commitment. In this exploit, the commitment hash for the forged ChangeAssetAdmin request never materially entered the accepted root calculation.
    • The bug is especially worth preserving because the exploit used a tiny edge-case discrepancy: for a one-leaf tree, leaf_index == 0 returned the leaf hash, while leaf_index == 1 made the verifier treat the leaf as belonging to no subtree and fall back to proof data. One digit changed the proof from authenticate this leaf to trust my supplied root fragment.
    • Hyperbridge’s revised loss disclosure matters because the headline ~$237K understated the broader bridge-security lesson. The forged message path was general admin authority over bridged assets, and the later reconciliation raised realized losses to roughly $2.5M across multiple EVM deployments.
    • Structurally, this is a strong cousin to bnb-chain-bsc-token-hub-iavl-proof-forgery-2022-10-06: both bridges lost because a lower-layer proof verifier vouched for source-chain state that never existed, then the application-layer bridge obediently minted or released value against that false answer.

Three bridge-truth promotions this incident collapsed

  1. Some bridge-shaped proof material existed at all
    • Hyperbridge already had a real historical overlayRoot, a bridge route willing to accept MMR proofs, and calldata fields that looked like one valid leaf-position / tree-shape story.
    • At this stage the strongest true fact was only the verifier is being shown root-shaped and proof-shaped material, not this exact ChangeAssetAdmin payload was ever committed on the source side.
  2. That proof material was promoted into canonical truth that this exact admin message leaf belonged to the trusted root
    • This was the decisive failure. HandlerV1 accepted attacker-supplied leaf_index / leafCount metadata without enforcing leaf_index < leafCount, and the one-leaf CalculateRoot() edge case let proof[0] stand in for the recomputed root while the forged message leaf never materially entered the calculation.
    • Hyperbridge therefore collapsed two different claims — a trusted root exists and this exact ChangeAssetAdmin request was proven inside that root — into the same runtime answer.
  3. That accepted bridge truth still deserved immediate DOT-control and mint authority on the destination side
    • Once the forged message passed verification, the route still let it mutate bridged-DOT admin and minter rights as if it were an ordinary control-plane message.
    • The later billion-token mint and DEX liquidation show how little blast-radius separation remained between one verifier edge case lied once and the attacker can now manufacture huge amounts of bridge-issued inventory against live liquidity across several EVM deployments.
  • Representative transactions and contracts:
    • Main exploit transaction: 0x240aeb9a8b2aabf64ed8e1e480d3e7be140cf530dc1e5606cb16671029401109
    • HandlerV1 verifier contract: 0x6C84eDd2A018b1fe2Fc93a56066B5C60dA4E6D64
    • TokenGateway contract: 0xFd413e3AFe560182C4471F4d143A96d3e259B6dE
    • Bridged DOT token on Ethereum: 0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8
    • Attacker EOA highlighted in public writeups: 0xC513E4f5D7a93A1Dd5B7C4D9f6cC2F52d2F1F8E7
    • Attacker’s pre-deployed mint / liquidation contract cited in public analysis: 0x31a165a956842aB783098641dB25C7a9067ca9AB
    • Minimal proxy used inside the exploit transaction: 0x518ab393c3f42613d010b54a9dcbe211e3d48f26
  • Response / mitigation:
    • Hyperbridge paused all bridging operations shortly after detection.
    • The team first disclosed roughly $237K of realized loss on Ethereum, then later revised the total to about $2.5M after reconciling two exploit phases and cross-chain losses on Ethereum, Base, BNB Chain, and Arbitrum.
    • Hyperbridge stated that remediation would target the underlying MMR proof-verification class rather than only the exact calldata used here, and that Token Gateway would remain paused until the patch was independently audited and extra safeguards were live.
    • The team also said it was tracing attacker flows, coordinating with exchanges and law enforcement, and planning token-based compensation if recovery efforts failed to make affected users whole.

Pattern tags

  • proof-to-message-binding-failure
  • bridge-verification-failure
  • Real historical overlayRoot stayed trusted while attacker-chosen proof metadata severed the binding between that root and the forged ChangeAssetAdmin payload
  • One verifier-edge bug inherited full bridge control-plane authority, then escalated into route-wide mint power because downstream blast radius still assumed perfect proof correctness

Why the exploit worked

  • Hyperbridge’s destination-side verifier still treated root matches trusted history as if it implied this exact message commitment participated in that history. The missing leaf_index < leafCount check broke that implication. By the time HandlerV1 returned proof valid, the bridge had already lost the only security object that mattered: one canonical authenticated message.
  • The decisive failure was not generic bad parsing. It was a proof-to-message binding collapse inside the one-leaf MMR edge case: valid leaf_index == 0 made the leaf hash matter, while invalid leaf_index == 1 let the verifier fall back to proof[0] and preserve the trusted root without ever recomputing it from the forged request commitment.
  • The forged message targeted ChangeAssetAdmin, which meant the exploit did not stop at one counterfeit withdrawal. One successful verifier lie rewired who counted as the legitimate DOT token admin on the destination side, and the later billion-token mint became an ordinary admin action from the bridge’s point of view.
  • Hyperbridge also lacked a route-local brake between one forged control-plane message passes verification and mint enough bridged DOT to empty available liquidity and incentive inventory across several EVM deployments. The verifier bug created authenticity failure; the uncapped admin and liquidity reach turned that failure into realized loss.
  • The preserved lesson is therefore stronger than audit the MMR library: bridge-proof systems still need one exact authenticated message object all the way down, and forged control-plane messages should not inherit treasury-scale downstream authority without local throttles, delays, or narrower admin surfaces.

Detection and audit pivots

  • Reconstruct the exact authenticated message object from the proof verifier’s inputs and outputs. If a trusted root can validate while the executed message commitment never materially participates in root recomputation, the bridge is already spending against counterfeit truth.
  • Force edge-case proofs around leafCount, leaf_index, empty subtrees, singleton trees, and path elements that may be skipped by helper logic. A proof verifier that behaves differently at 0, 1, or empty-collection boundaries is part of the custody surface, not just a serialization helper.
  • Audit every admin or configuration message the bridge can import over the same verification rail as user transfers. A forged change admin, set token, or update route message is usually more dangerous than a single fake withdrawal because it can manufacture future honest-looking withdrawals.
  • Ask what destination-side powers remain after one forged message lands. If the route can still mint uncapped wrapped supply, rotate admin, or drain multiple chain-local liquidity pools before any per-asset limit or delay triggers, the bridge still assumes verifier perfection where it should assume eventual verifier failure.
  • Review proof libraries and caller-side bounds checks together. Hyperbridge failed partly because HandlerV1 trusted the proof helper to reject impossible metadata and the proof helper trusted the caller to supply well-formed indices. That split is itself a bridge-authenticity hazard.

Failure-prevention checklist

  • Enforce leaf_index < leafCount and equivalent subtree-shape invariants in both the caller and the proof helper. If a route treats one MMR proof as bridge truth, impossible singleton-tree indices are authenticity failures, not parser clean-up work.
  • Make the verifier consume the claimed message commitment explicitly. ChangeAssetAdmin should not become executable because a helper returned a trusted overlayRoot; the route should prove that the exact serialized admin payload was the leaf the MMR path authenticated.
  • Prefer route-local proof-shape minimalism over inherited upstream flexibility. If Token Gateway only needs one exact post-request leaf, reject proof forms, subtree combinations, or one-leaf edge behaviors that the route does not actively rely on.
  • Treat imported admin messages as treasury-grade actions. Changes to token admin, minter, registry, or route control should sit behind additional pauses, delayed execution, or narrower capability scopes even after proof verification succeeds.
  • Bound post-verification blast radius per route and per asset. One forged control-plane message should not have immediate line-of-sight to unlimited wrapped-supply minting plus every live liquidity and incentive pool on multiple destination chains.
  • Keep one source-side provenance record for every destination execution. Operators should be able to point from each admin mutation or mint event to one exact source message hash, claimed leaf index, leaf count, and accepted root, then reconcile that object against source-side logs.
  • Regression-test the exact bad edge case. Singleton-tree proofs with leafCount = 1 must reject leaf_index = 1, and any proof where proof[0] equals a trusted root but the claimed message leaf never enters recomputation must fail end to end.
  • Review imported proof libraries as custody dependencies. When a bridge mirrors upstream consensus or storage code, the route still needs a separate review of which helper behaviors remain safe once proof passed directly authorizes mint, release, or admin control.
  • Design bridges to survive one verifier miss. Per-asset mint ceilings, per-epoch withdrawal limits, route-local pauses, and delayed control-plane execution should already assume that message-membership verification can eventually fail.

Audit prompts

  • Where is the exact route-local assertion that leaf.index < proof.leafCount, and does that invariant survive every helper call path into MMR verification?
  • If the verifier accepts a request, can reviewers reconstruct the exact serialized PostRequest or ChangeAssetAdmin payload hash that actually participated in root recomputation, not just the historical overlayRoot that matched?
  • Do singleton-tree, empty-subtree, and out-of-bounds leaf-index cases ever let proof[0], default values, or skipped branches stand in for the claimed message leaf?
  • Which destination-side actions share the same proof rail as ordinary user transfers, and what stops one forged control-plane message from escalating into mint-authority seizure or route-wide configuration capture?
  • If one imported admin message were forged today, what onchain throttle limits the amount of bridged supply, pool inventory, or incentive inventory that could be monetized before operators pause the route?
  • Are proof-helper assumptions and caller assumptions written down in one place, or is the bridge still depending on caller validates indices and library validates structure folklore that leaves gaps between the two?
  • Can monitoring tie each accepted bridge execution to one exact source-side message commitment, leaf index, leaf count, and trusted root, or does telemetry stop at proof verified?
  • During upgrades, what test proves that old and new MMR verification paths still bind the same exact message object rather than merely returning the same root type on happy-path inputs?
  • If a reviewer mutates only the leaf index, subtree metadata, or admin payload while preserving a real historical root, does the route fail every time?

Lessons that should already be standard

  • Trusted root matched is not enough. The route is safe only when the exact executable message leaf, including admin payloads, was forced into the authenticated root computation.
  • Bounds checks inside proof metadata are bridge-authenticity logic. Treating leaf_index < leafCount as optional input hygiene is how one real root becomes counterfeit bridge truth.
  • Upstream-proof compatibility is not a security argument by itself. A helper that is reasonable inside Polkadot’s broader context can still be too permissive once an EVM bridge promotes its output into direct mint and admin authority.
  • Admin messages are bridge liabilities, not maintenance details. A forged ChangeAssetAdmin proof can be worse than one fake withdrawal because it manufactures future honest-looking mint actions.
  • Proof-based bridges still need bounded-loss design. Hyperbridge’s verification bug created fake authenticity; the uncapped destination-side mint and pool reach turned that single lie into multi-chain realized loss.
  • Monitoring that only records proof accepted is incomplete. Bridges should already be able to answer which exact source-side message commitment authorized each destination-side admin mutation or asset release.
  • One verifier bug is enough reason to review every route, asset, and control-plane surface that inherits the same proof rail. The blast radius is architectural, not just transactional.

Why this incident matters

  • It preserves a clean example of proof-heavy branding still collapses at the verifier edge. The bridge did not need a stolen signer, a fallback committee, or a compromised relayer to fail; one missing bounds check was enough.
  • It is also a useful bridge-security cousin to Nomad and BNB Chain. Nomad accepted default zero proof state as authentic, BNB Chain accepted a forged IAVL range proof, and Hyperbridge accepted a forged MMR proof whose computed root ignored the supplied message leaf.
  • It also sharpens the admin-message branch of bridge risk. The forged proof did not just counterfeit one withdrawal; it counterfeited ChangeAssetAdmin, which immediately rewired who could mint bridged DOT and made future cash-out a normal token-admin action.
  • Finally, it preserves the separate bounded-release lesson: one verifier mistake still had line-of-sight to multi-chain DOT pools plus associated incentive inventory, so a single fabricated admin message escalated into route-wide mint authority and cross-venue liquidation before operators could contain the lane.

Internal linkages

  • Core recurring pattern: proof-to-message-binding-failure.
  • Sharper subfamily: proof-to-message-binding-failure — Hyperbridge did not just accept a bad root; it accepted a real root without proving that the forged ChangeAssetAdmin message commitment actually participated in it.
  • Positive-design companion: bridge-truth-security-object — useful when the sharper question is what one canonical authenticated bridge object should have fused overlayRoot, leaf position, message commitment, and executable destination-side admin action before any DOT-control change became legal.
  • Positive-design companion: bridge-message-membership-exactness-and-minimal-proof-shape-discipline — the sharper healthy-side companion for how Hyperbridge should have forced one exact ChangeAssetAdmin message leaf through one minimal one-leaf proof shape instead of accepting verifier metadata flexible enough to preserve a real root while dropping the forged payload from recomputation.
  • Positive-design companion: bridge-bounded-release-design — useful when the sharper question is why one forged control-plane message still had enough downstream mint and pool reach to realize losses across multiple EVM routes before the bridge halt.
  • Closest structural cousin: bnb-chain-bsc-token-hub-iavl-proof-forgery-2022-10-06 — both incidents turned a lower-layer proof-verifier bug into forged bridge truth.
  • Useful contrast case: nomad-bridge-invalid-proof-acceptance-2022-08-01 — Nomad broke through verifier state semantics, while Hyperbridge broke through verifier input-validation and root-reconstruction semantics.
  • Protocol context: hyperbridge.

Control surface

Graph View

Backlinks