Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
A cross-chain bridge vulnerability lets an invalid source-chain event cause an unauthorized action on a destination chain, or prevents a valid event from completing. Bridges combine contracts, consensus assumptions, relayers, signers or proofs, token accounting, and upgrade controls. A correct destination contract is therefore only one part of the security boundary.
Message authentication must bind the source chain, source emitter, payload, and intended destination or application. Verifying valid signatures is insufficient if the signer set is wrong, the emitter is not trusted, or the same message can be consumed twice.
Replay protection normally records a protocol-defined message identifier. For example, Wormhole's VAA documentation describes messages indexed by emitter chain, emitter address, and sequence, with destination applications responsible for validating the emitter and payload. Other bridges use light-client proofs, optimistic challenges, or different quorum schemes. Review the guarantees of the actual design.
Finality is another boundary. A message accepted before its source event is final may conflict with a later chain reorganization. Token bridges also need conservation rules across lock, mint, burn, and release paths, including fees, decimal conversions, failed deliveries, and canonical versus wrapped assets.
Trace one message from source initiation through observation, proof or signature production, relay, destination verification, execution, and acknowledgement. At each step, record which fields are authenticated and who can change the trusted verifier, signer set, emitter, or implementation.
Test valid messages plus wrong-chain, wrong-emitter, wrong-destination, malformed-payload, duplicate, reordered, expired, and old-signer-set cases. Simulate source reorganizations and partial system failure. Fuzz amount and decimal conversions, fee deductions, tokens with unusual transfer behavior, and retry paths after destination execution reverts.
Bridge invariants should reconcile outstanding locked assets, minted representations, completed burns, and releases for each asset and route. A single aggregate counter is not enough when messages can be pending or refunded.
Use the bridge's canonical verification routine, then validate application-specific fields before changing state. Mark a message consumed before external interactions, subject to the protocol's retry model. Separate pausing from arbitrary fund movement, constrain upgrades, and design rate limits around credible failure modes.
Quorum is not a synonym for decentralization. Wormhole's security documentation explicitly states its Guardian, governance, finality, and accounting assumptions; every bridge should make comparable assumptions reviewable. A pause or rate limit may reduce loss during response, but cannot correct forged state already accepted elsewhere.
Repository analysis can identify missing field checks, replay mappings, unsafe initialization, and local accounting errors. It cannot prove source-chain finality, validator key security, relayer availability, or global asset conservation without the contracts, configuration, and state from every participating chain.
Must every bridge verify a multisignature?
No. Some verify validator signatures; others verify light-client proofs or accept messages after an optimistic challenge. The implementation must enforce its stated trust model.
Is a relayer necessarily trusted?
Not always. A design can let any relayer submit authenticated messages, limiting relayers to delaying or censoring delivery. Verify the actual protocol rather than assuming this property.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand missing and incorrect smart contract authorization checks, how to review privileged paths, and how to test role boundaries.
Understand untrusted delegatecall targets, proxy upgrade boundaries, storage hazards, and practical review and test guidance.
Understand how atomic liquidity amplifies oracle, accounting, governance, and callback defects, with review and test guidance.
Understand governance capture, flash-loan voting, unsafe proposal execution, and the review and testing needed for on-chain governance systems.
Understand unsafe price-feed consumption, stale and low-liquidity data, oracle trust assumptions, and practical review and mitigation techniques.