Vulnerabilities

Replay Attack

A replay attack reuses a valid transaction, signature, message, or proof in a context where it should only be valid once.

A replay attack uses the same approval or message again when the contract should reject it.

Replay Attack Explained in Detail

A replay attack happens when valid data is accepted more than once or in the wrong context. The replayed item might be a signature, permit, bridge message, withdrawal proof, order, or transaction payload.

Replay protection usually uses nonces, deadlines, chain IDs, contract domains, and used-message tracking.

Smart contract example

require(!used[digest], "used");
used[digest] = true;

The contract marks the approved digest as used before it performs the sensitive action.

Replay Attack in Auditing

Replay attacks can duplicate withdrawals, claims, orders, approvals, or cross-chain messages. They are common anywhere off-chain data authorizes on-chain action.

Auditors check exactly what context is bound to the approval and exactly when it is consumed.

Red flags in code

  • Signed data omits nonce, deadline, chain ID, or contract address.

  • A used mapping is updated after external calls.

  • Bridge messages do not track consumed message IDs.

  • The same proof can claim more than once.

  • Signatures are tracked by raw bytes instead of digest and nonce.

How to test or review it

  • Submit the same signature, proof, or message twice.

  • Replay across chains, contracts, users, and epochs.

  • Mutate context fields and check validation.

  • Test cancellation and nonce invalidation.

  • Confirm used-state updates happen before risky interactions.

Practice this in real audit scenarios

Definitions help, but auditors need reps. SCH turns concepts like Replay Attack into exploit labs, code review habits, and report-writing practice.

Start the free trial or see the full smart contract auditing course.

Sources