Web3Exploit logoWeb3Exploit
← Back to Attack Patterns
Attack pattern

Bridge Exploits

Cross-chain bridges concentrate value and trust; a flawed message-verification or signer set lets an attacker forge withdrawals.

Definition

Bridges lock value on one chain and mint/release it on another based on a verification mechanism (multisig, light client, or proof). Exploits target that verification — forging or replaying messages, compromising the signer set, or abusing an initialization/validation flaw — to withdraw without a legitimate deposit.

How it works

  1. The bridge releases funds when it accepts a 'valid' cross-chain message or proof.
  2. The attacker forges, replays, or improperly satisfies that verification (e.g. a spoofed proof or a compromised guardian quorum).
  3. The bridge mints or releases assets with no backing deposit, draining the locked pool.

Vulnerable vs. fixed

Vulnerable: weak or spoofable message verificationsolidity
function withdraw(bytes calldata message, bytes calldata proof) external {
    // Verification that can be forged/replayed (no domain/replay binding).
    require(verify(message, proof), "bad proof");
    _release(message); // releases funds on a spoofable check
}
Fixed: bind, bound, and de-duplicate messagessolidity
function withdraw(bytes calldata message, bytes calldata proof) external {
    bytes32 id = keccak256(message);
    require(!processed[id], "replayed");
    require(verifyWithDomain(message, proof, chainId), "bad proof");
    processed[id] = true; // effects before release
    _release(message);
}

Detection steps

  1. Identify the sensitive value or permission the pattern can influence.
  2. Trace every path that can update or consume that value, including callbacks, routers, and privileged helpers.
  3. Reproduce the worst-case attacker flow with adversarial ordering, manipulated inputs, and maximum feasible capital.

Common signals

  • Security depends on an assumption that is not enforced by code.
  • A critical value is consumed immediately after an attacker-controlled interaction.
  • A privileged call path crosses multiple contracts without one clear authorization boundary.

False positives

  • The risky-looking operation is read-only and cannot affect settlement or authorization.
  • The value is bounded by independent checks before it moves assets.
  • All privileged entry points share the same tested guard and monitoring path.

Review questions

  • Which invariant would fail if this input or caller were attacker-controlled?
  • Can the attacker compose setup, trigger, settlement, and cleanup atomically?
  • What independent check stops the exploit if the first guard is wrong?

Defensive checklist

  • Bind messages to a domain (chainId, bridge address) and enforce replay protection.
  • Harden the trust root: threshold signatures, key rotation, monitored guardians.
  • Validate proofs against a canonical source; reject partially-verified messages.
  • Rate-limit and monitor withdrawals for anomalies.
Related glossary