Signature Replay

Signature Replay Explained in Detail

Signature replay happens when a valid signature can be submitted more than once, or submitted in a different context than intended.

The attacker does not forge the signature. They reuse something valid.

Smart contract example

A contract lets users withdraw with a signed message:

bytes32 digest = keccak256(abi.encodePacked(user, amount));

If there is no nonce, the same signature can withdraw repeatedly. If there is no chain or contract binding, the signature may also work on another deployment.

Signature Replay in Auditing

Signature replay turns a one-time authorization into something an attacker can reuse. It commonly affects withdrawals, permits, claims, swaps, delegated calls, bridge messages, and governance votes. That often makes it an access control bug.

The first execution often succeeds normally, so happy-path tests may miss the replay.

Red flags in code

• No nonce, salt, bitmap nonce, or used-message tracking.

• Nonce is checked but not consumed.

• Deadline is missing.

• Signed hash omits block.chainid or contract address.

• Same signature is valid across multiple functions.

• Signature bytes are tracked instead of message hash or nonce.

• abi.encodePacked is used for complex signed data.

• ecrecover accepts malleable signatures.

How to test or review it

• Submit the same signature twice.

• Try the same signature with a different recipient, amount, function, contract, and chain if the setup allows it.

• Verify that nonces are consumed before any risky external interaction.

• Check that the signed data includes all execution-critical fields.

• Review EIP-712 domains and Permit2 integrations carefully.

• Use the Keccak-256 tool to reproduce simple signed digests during review.