Cowrie Research

proof-to-message-binding-failure

16 min read

Proof-to-Message Binding Failure / Authenticated Root Detached from Claimed Leaf

  • Name: proof-to-message binding failure / authenticated root detached from claimed leaf
  • Category: exploit pattern / bridge security failure / proof-verifier failure / message-membership failure / root-leaf decoupling
  • Summary: Some bridges correctly check that a root, header, or commitment anchor is trusted, but fail the more important follow-up question: did the specific message being executed actually participate in that authenticated commitment? The bug class appears when a proof verifier can be tricked into returning a real root while silently dropping, ignoring, or misbinding the attacker-chosen leaf or message payload. Once root is trusted drifts away from this exact message was proven under that root, the downstream bridge executes a forged withdrawal, mint, or admin action against authenticity that was never really earned.
  • What it is:
    • A bridge authenticates inbound messages by verifying a Merkle proof, range proof, MMR proof, light-client proof, or similar membership witness against a trusted root or header.
    • The implementation assumes that if the recomputed root matches the trusted anchor, then the requested message must have been included.
    • A verifier bug breaks that binding between authenticated root and claimed message commitment.
    • The break can come from out-of-bounds leaf indices, ignored proof branches, malformed range-proof semantics, inconsistent edge-case handling, or parser paths that let attacker-controlled proof data substitute for a computed subtree.
    • The bridge still sees a valid-looking root or header, so application-layer logic accepts the attacker-crafted message as authentic.
    • Real value is then released or minted through the ordinary bridge execution path.
  • Typical preconditions:
    • The bridge uses low-level proof verification as direct release or mint authority.
    • The proof library accepts attacker-supplied leaf indices, proof arrays, branch metadata, or subtree sizes.
    • The verifier does not enforce basic structural invariants such as leaf_index < leafCount, unique path shape, or exact one-leaf semantics where required.
    • Destination-side execution trusts proof passed without a second sanity check on message identity, asset amount, or admin intent.
    • A successful forged message can immediately reach high-value mint, withdrawal, or permission-changing code.
  • Common vulnerable surfaces:
    • Merkle Mountain Range verifiers with underconstrained leaf-index or subtree-bound checks
    • IAVL or range-proof verifiers whose inner-node hashing and recursive proof semantics disagree about which branches matter
    • light-client precompiles or helper libraries that accept more expressive proof forms than the bridge actually knows how to constrain safely
    • message handlers that pass user-supplied proof metadata into generic proof libraries without validating shape first
    • single-leaf edge cases where invalid indices or empty subtree handling collapse to attacker-supplied proof fragments
    • bridge flows where authenticated admin messages can directly change minter, upgrader, or asset-manager authority
  • Exploit sequence:
    1. The attacker identifies a proof-verifier path where trusted root matched does not strictly imply claimed message commitment was proven.
    2. They craft proof metadata so the verifier authenticates a real stored root or header while dropping, bypassing, or misbinding the forged leaf.
    3. The verifier returns success because the trusted anchor still matches.
    4. The bridge interprets that success as proof that the attacker-chosen message, transfer package, or admin action is canonical.
    5. Destination-side bridge logic executes the forged message and releases or mints real value.
    6. The attacker cashes out before operators pause the route.
  • Variants:
    • Out-of-bounds leaf-index bypass — the verifier accepts an impossible leaf position, and edge-case handling turns attacker-supplied proof data into the returned root, as in Hyperbridge.
    • Ignored branch / asymmetric hash semantics — one branch of an inner-node proof is security-critical in some contexts but silently ignored in another, so attacker edits preserve the trusted root while changing the proven payload, as in BNB Chain.
    • Malformed range-proof acceptance — the verifier accepts proof forms whose expressive power exceeds the application-layer bridge’s safety assumptions, so one real proof can be reshaped to vouch for extra attacker-invented leaves.
    • Root-valid, message-unbound admin call — the forged proof does not just release one asset transfer but authenticates a privileged control-plane message, turning proof failure directly into minter or admin seizure.
  • Detection heuristics:
    • Ask the verifier two separate questions: is this root trusted? and did this exact message commitment participate in that trusted root?
    • Fuzz edge cases around leafCount, leaf_index, empty branches, one-leaf trees, duplicate branches, and malformed range proofs.
    • Review whether the proof library can return a valid root while some attacker-supplied proof branches or leaves were never actually consumed in root construction.
    • Compare application-level assumptions with proof-library expressiveness; if the bridge expects one message proof but the verifier accepts richer proof shapes, assume danger.
    • Treat bounds checks and subtree-shape checks as authenticity checks, not mere input hygiene.
    • Separate was this exact message authenticated? from did later accounting settle the same economic object? If message membership is real but a downstream consumer can still credit, release, or withdraw against a narrower or different effect set, the failure has crossed over into proof-to-effects binding failure.
    • Look for admin or asset-control messages whose authenticity depends entirely on a generic proof helper below them.
  • Defenses:
    • Enforce structural invariants before calling the generic proof library: valid leaf index, valid subtree size, expected proof arity, and exact message-leaf count.
    • Prefer proof verifiers whose APIs make the proven leaf or message commitment explicit rather than reconstructing identity indirectly from permissive proof metadata.
    • Reject proof forms the bridge does not actually need, especially multi-leaf or range-proof variants when one-leaf membership is sufficient.
    • Add tests that prove the authenticated root changes if any security-relevant leaf, branch, or sibling is changed.
    • Treat low-level proof libraries as custody code and audit edge-case branches with the same severity as bridge release logic.
    • Add rate limits and asset/admin circuit breakers so one verifier bug cannot instantly turn into unlimited mint or release authority.

Three bridge-membership promotions reviewers should not collapse

  • A proof-shaped artifact exists — some witness, branch set, range proof, or leaf-index declaration can be fed into the verifier and may even return a real trusted root or header.
  • That artifact counts as canonical truth that this exact executable message lived under that trusted root — this is the real bridge-authenticity promotion, and it is where BNB Chain and Hyperbridge failed.
  • That accepted message-membership truth still deserves live mint, withdrawal, or admin authority on the destination side — even after a route believes membership is real, bounded release and typed control-plane handling still decide how catastrophic one verifier mistake becomes.

What sound design looks like

  • Healthy bridge review keeps three separate questions explicit: what witness-shaped artifact exists?, did it really prove this exact executable message?, and if we say yes, how much destination-side authority does that message get right now? Flattening those into one fuzzy proof passed event is how real trusted roots end up authorizing counterfeit payloads.
  • One trusted root should authorize one exact executable message object. The bridge should not separately reason about trusted commitment, claimed message, and runtime payload as loosely related artifacts; it should prove that the exact bytes being executed are the bytes committed under the authenticated root. Bridge truth as a single security object is the broader positive-design companion for that one authenticity object goal.
  • Proof metadata should narrow, not widen, what the verifier is allowed to accept. Leaf indices, subtree sizes, proof-depth declarations, and range bounds should be treated as part of the authenticity claim rather than as friendly hints to a generic helper.
  • The safest bridge API is explicit about the message commitment it is proving. A healthy verifier consumes trusted root + claimed leaf + exact witness and returns success only when all three bind to one another, not when one of them can silently drop out and the root still looks real.
  • Compatibility with an upstream proof library or consensus implementation is not a safety argument by itself. Hyperbridge’s MMR helper was written to mirror upstream Polkadot semantics, and BNB Chain inherited a dangerous IAVL proof shape from Cosmos-adjacent code, but the bridge route still needed to constrain the narrower question it was actually asking: did this exact executable bridge message live under the trusted root?
  • Privileged bridge actions should inherit the same exact-membership discipline as withdrawals. A control-plane message like set admin, mint authority, or upgrade route is still bridge truth and should not be executable merely because some nearby commitment was authentic.
  • The clean reviewer question is: if the bridge executes this exact message bytestring, where exactly did the verifier force those bytes, and not just a compatible root, to participate in the authenticated commitment?

Failure-prevention checklist

  • Define one canonical message commitment format per route and hash the exact executable payload fields into it: source chain, source contract, nonce, destination contract, function intent, asset identity, recipient, and amount.
  • Make the bridge prove a stricter statement than this witness returned a trusted root. The route should only promote verifier output into message-membership truth after it has bound one exact claimed message commitment to one exact allowed proof shape.
  • Enforce proof-structure invariants before any root comparison: valid leaf index bounds, expected tree size, expected proof depth, allowed branch shapes, and exact arity for the proof form the route claims to use.
  • Prefer one-leaf membership proofs where possible. If the bridge does not need range proofs, batch witnesses, or multi-message proofs, reject them entirely instead of trying to safely ignore their extra expressiveness.
  • Require the verifier API to consume the claimed leaf or message hash explicitly. Avoid helper functions that only return a recomputed root while leaving it implicit which leaf data actually mattered.
  • Add adversarial tests for every edge case that can separate root validity from message membership: leaf_index = 0, leaf_index = leafCount, leafCount = 0/1, duplicate branches, empty proof arrays, overlong proof arrays, malformed subtree sizes, and attacker-supplied siblings that go unused.
  • Treat authenticated admin messages as treasury events. Changes to mint authority, asset-manager roles, bridge routes, or token registry control should sit behind pauses, rate limits, or delayed execution just like large withdrawals.
  • Keep message-membership truth and destination-side authority as separate promotions. Even if a route believes one message was proven, per-message caps, slower privileged lanes, and typed handlers should still stop that belief from immediately becoming uncapped custody authority.
  • Shadow-verify message identity in monitoring and incident tooling. The bridge should be able to show which committed leaf hash, which source event, and which destination execution correspond to every released or privileged action.
  • Keep bridge release paths blast-radius bounded even if proof membership fails once: per-asset caps, per-message spending ceilings, route pauses, and delayed large governance or admin actions.
  • Review upgrades to proof libraries, tree formats, and serialization logic as custody migrations. Any change in proof expressiveness or message encoding can silently redefine what counts as membership proven.
  • If the bridge ports or adapts an upstream proof helper, write route-local invariants for the smaller claim the bridge actually needs. Matches upstream is weaker than cannot authenticate any message form except the exact one this route executes.
  • Reconcile released value and privileged state changes against the source-side committed message log so counterfeit execution surfaces quickly.

Audit prompts

  • What exact bytestring or leaf hash is supposed to be proven, and where is that object serialized before the verifier ever sees it?
  • At what exact line does the route promote witness/root artifact exists into this exact executable message was proven, and at what later line does it promote that accepted message into live release, mint, or admin authority?
  • Can the verifier return a trusted root even if some attacker-controlled branch, sibling, or declared index was never actually consumed in the root computation?
  • Does any proof metadata such as range bounds, subtree size, or index width have looser semantics in the generic library than in the bridge route that calls it?
  • If the verifier was copied or adapted from an upstream consensus or storage proof library, what assumptions were safe there but become unsafe once the bridge treats proof success as direct mint, withdrawal, or admin authority?
  • Are there one-leaf, empty-tree, first-leaf, last-leaf, or out-of-bounds edge cases where the proof helper falls back to attacker-supplied proof fragments or default values?
  • If the bridge executes an admin or mint-control message, where exactly is the proof that this control-plane payload, not just some nearby authenticated root, was committed on the source side?
  • Are there proof forms accepted by the helper that the application never intended to support, and can those richer forms be reshaped to vouch for an attacker-invented leaf?
  • Does monitoring record the proven message commitment and the executed destination payload in a way that would catch root-valid / message-unbound execution quickly?
  • If one forged membership proof lands, what onchain limit actually stops uncapped withdrawal, mint, or admin escalation before operators intervene?
  • During upgrades, what test proves old and new proof verifiers still bind exactly the same message object rather than merely the same root type?
  • If a reviewer mutates one security-relevant bit of the claimed message while keeping the same trusted root, does the whole flow fail end to end every time?

Lessons that should already be standard

  • Trusted root matched is not the bridge security invariant. The invariant is the exact executed message was committed under the trusted root.
  • A witness exists, that witness proves this exact message, and that message deserves live custody authority are three separate promotions. Collapsing them into one proof passed mental model is how bridges turn real roots into fake withdrawals or forged admin actions.
  • Proof-library edge cases are not parser trivia. In bridge code they are release authority and deserve the same review intensity as withdrawal authorization logic.
  • The more expressive the proof form, the more ways the bridge can accidentally ask the wrong question. Supporting only the minimal witness shape you actually need is usually a security improvement.
  • We mirrored upstream proof code is not a bridge-security argument. A helper that is reasonable inside a broader consensus or storage context can still be fatally over-expressive once a bridge promotes proof passed into direct mint, withdrawal, or admin authority.
  • Admin messages are bridge liabilities too. A forged change admin proof can be economically worse than one counterfeit withdrawal because it can manufacture unlimited future withdrawals.
  • Bounds checks and path-shape checks are authenticity checks. Treating them as mere input hygiene is how root-valid, message-fake execution survives review.
  • A bridge should be able to answer which exact source-side commitment authorized each destination-side execution. If that provenance is implicit or hard to reconstruct, the route is already too trusting.
  • Healthy bridge monitoring needs to reason about message identity, not only root acceptance. Root-valid counterfeit execution is exactly the class of bug that slips through if telemetry stops at proof verified.

What sound bridge-proof review looks like

  • Write down the exact executable message object before touching the proof helper: source chain, source contract or channel, nonce, destination route, action type, asset identity, amount, recipient, and any admin or upgrade payload bytes. Review should start from what exact destination-side effect are we claiming the source side committed?, not from what proof API do we already have?

  • Force the verifier call to consume the claimed message commitment explicitly. A healthy review path can point to one line where the route binds trusted root, claimed message hash, and exact witness into one success condition, and to a different later line where that accepted message is promoted into live mint / release / admin authority.

  • Shrink proof expressiveness until it matches route needs. If the bridge only needs one-leaf membership, reviewers should be suspicious of range proofs, permissive subtree metadata, optional siblings, empty-branch conventions, or helper APIs that were designed for a richer upstream environment than this route actually needs.

  • Treat edge-case arithmetic and shape checks as part of the authenticity proof, not as parser hardening. Hyperbridge and BNB Chain preserve the same review lesson from different proof families: the dangerous branch is the one that lets the verifier keep a real trusted root while silently losing the exact leaf the bridge thinks it authenticated.

  • Review admin and control-plane messages as treasury events. A forged withdrawal is bad; a forged set admin, set minter, or route-management message can make every later withdrawal authentic-looking too. If one proof bug can reach control-plane handlers, the blast radius is much larger than the first counterfeit transfer.

  • Require provenance telemetry that survives incident pressure. Operators should be able to show this executed destination payload came from this exact source commitment under this exact trusted root without re-deriving the whole proof story manually from raw logs and library assumptions.

  • Keep bounded-release controls close anyway. Even when exact membership looks proven, bridges should still slow or cap large withdrawals and privileged messages so a single membership-binding bug does not become route-wide insolvency before humans can react.

  • High-signal incidents:

    • [[../../../incidents/bridges-crosschain/hyperbridge-token-gateway-mmr-proof-forgery-admin-takeover-dot-mint-2026-04-13|Hyperbridge Token Gateway MMR proof forgery / forged ChangeAssetAdmin DOT mint (2026-04-13)]] — the clean trusted root, forged message exemplar: an out-of-bounds one-leaf MMR proof made CalculateRoot() return attacker-chosen proof[0], so Hyperbridge accepted a fabricated admin message even though the forged commitment never participated in the authenticated root.
    • forged BNB mint (2022-10-06) — the strong range-proof cousin: the IAVL verifier’s inner-node hash logic ignored Right whenever Left existed, so an attacker could splice a malicious extra leaf into a real proof and preserve the same trusted appHash while proving data the Beacon chain had never committed.

Internal linkages

Control surface

Graph View

Backlinks