Signature replay vulnerabilities in disclosed bug bounty reports
A signature that does not bind chain, contract, nonce and purpose can be replayed somewhere the signer never intended.
- Reports indexed
- 15
- Total paid
- $2.6M
- Critical
- 1
- Largest payout
- $2.5M
Signature schemes fail on what they omit. A payload that signs an amount and a recipient but not a nonce can be submitted twice. One that omits the chain ID can be replayed on every fork and every testnet. One that omits the verifying contract address can be replayed against a sibling deployment that shares a signer.
EIP-712 exists to make this hard to get wrong, and most findings in this class are cases where it was adopted partially — a domain separator cached at deploy time and never rebuilt after a fork, a type hash that does not cover every field actually used, or a nonce that is read but never incremented.
The second cluster is malleability and recovery: accepting both `s` values for the same signature, treating a zero address returned by `ecrecover` as a valid signer, and permit implementations that fall back to a code path with weaker checks.
What reviewers look for
- Signed payloads missing a nonce, deadline, chain ID or verifying contract
- Domain separators cached at construction rather than derived per call
- `ecrecover` results not checked against the zero address
- Nonces read but never persisted or incremented
- The same signer authorised across multiple deployments or chains
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Cross-chain bridge signature replay allows infinite mint
A signature validation vulnerability in a cross-chain bridge protocol allowed valid guardian attestations to be replayed across different destination chains. The signed message digest omitted essential domain parameters like the target chain ID and global emitter sequence, allowing an attacker to reuse a single legitimate withdrawal signature on multiple bridge deployments. Consequently, an attacker could mint unlimited wrapped assets across various target chains without providing additional collateral on the source chain.
NFT marketplace signature does not bind to token id allowing order swap
An NFT marketplace implemented an off-chain EIP-712 order signing mechanism that failed to include the token ID within the signed struct hash. Because the token ID was accepted directly from unverified calldata during order execution, malicious actors could swap order parameters to fulfill trades using unintended token IDs from the same collection. This allowed attackers to acquire high-value collection items using floor-priced signatures or trade arbitrary assets under invalid terms.
Crestal Network: Signature Replay attack possible on `updateWorkerDeploymentConfigWithSig()` in Blueprintcore.sol which leads to users lose the funds
Crestal Network's BlueprintCore.sol exposes updateWorkerDeploymentConfigWithSig(), which verifies a signer against a digest built by getRequestDeploymentDigest. Because that digest omits any per-user nonce, timestamp, or chain ID, a validly signed configuration-update message can be replayed indefinitely. Each replay re-runs updateWorkerDeploymentConfigCommon and its payWithERC20 fee logic, repeatedly draining the deployment owner's approved token balance to the fee collection wallet, with the protocol lacking any refund path. The protocol team fixed the issue by binding a per-user nonce into the signed digest and incrementing it after each call.
Chakra: `ChakraSettlement.receive_cross_chain_msg` and `ChakraSettlement.receive_cross_chain_callback` functions do not ensure that receiving `ChakraSettlement` contract's `contract_chain_name` must match `to_chain` corresponding to respective `txi…
Chakra's cross-chain settlement functions sign and verify messages that do not bind the signed payload to the receiving chain's identity. Because validators and handlers can be deterministically deployed to the same address on multiple chains and can share identical whitelist configurations, a message and its validator signatures intended for one destination chain can be replayed on another. An attacker can therefore trigger `receive_cross_chain_msg` or `receive_cross_chain_callback` on the wrong chain, producing incorrect token mints, unlocks, or burns. The impact is incorrect token accounting across chains, which the judge escalated to high severity as a replay vulnerability on received funds.
Chakra: The `receive_cross_chain_msg` function has potential replay attack risks
Chakra's Cairo handler accepts inbound cross-chain messages via `receive_cross_chain_msg`, verifying only caller identity and supported handler roles while never recording which message IDs have already been executed — that responsibility lives entirely in the separate settlement contract. Because the owner can call `upgrade_settlement` to repoint `settlement_address` at a replacement contract whose storage is fresh, previously executed messages are erased from the system's memory even though the validator set is unchanged. An attacker holding a previously signed and executed cross-chain message can then resubmit it, and all checks still pass, producing duplicate credits or repeated state transitions. The judge confirmed this as an acceptable medium-risk edge case, since settlement replacement without validator rotation is a plausible upgrade flow.
Gondi: `refinanceFull`/`addNewTranche` reusing a lender's signature leads to unintended behavior
Both refinanceFull() and addNewTranche() in Gondi's MultiSourceLoan validate a lender's signature against the identical RenegotiationOffer hash, so a single signature is ambiguous about which operation the lender consented to. A malicious borrower can take an offer signed for a full refinance and front-run the intended call by submitting the same sig to addNewTranche(), which imposes much weaker constraints. This appends a new tranche on top of the existing principal, roughly doubling the loan's outstanding amount and materially increasing the lender's credit risk beyond what they agreed to. The sponsor confirmed the issue and attempted a trancheIndex-based fix, but the Code4rena mitigation review marked the finding unmitigated.
All reports in this group
- Revert Lend: `V3Vault.sol` permit signature does not check receiving token address is USDCSignature replay$0
- Taiko: Signatures can be replayed in `withdraw()` to withdraw more tokens than the user originally intended.Signature replay$0
- zkSync: Discrepancy in ECRECOVER Precompile when Using `Delegatecall`Signature replay$0
- Ethereum Credit Guild: Replay attack to suddenly offboard the re-onboarded lending termSignature replay$0
- Collective: `encodedData` argument of `hashStruct` is not calculated perfectly for EIP712 singed messages in `CultureIndex.sol`Signature replay$0
- Paladin: EIP712 chainId is hardcoded which can cause replay attacks in case of hardforkSignature replay$0
- Biconomy: Cross-Chain Signature Replay AttackSignature replay$0
- Biconomy: Replay attack (EIP712 signed transaction)Signature replay$0
- Biconomy: Destruction of the `SmartAccount` implementationSignature replay$0