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
- 8
- 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.
Revert Lend: `V3Vault.sol` permit signature does not check receiving token address is USDC
Revert Lend's V3Vault contract contains a critical input validation vulnerability regarding its use of Uniswap Permit2 for asset transfers. When performing deposits or liquidations, the contract fails to verify that the token specified in the Permit2 signature matches the vault's required underlying asset. An attacker can exploit this by signing a permit for a worthless token, which the vault then erroneously accepts as a valid deposit of the vault's asset, enabling unauthorized fund theft or protocol state manipulation.
Ethereum Credit Guild: Replay attack to suddenly offboard the re-onboarded lending term
In the Ethereum Credit Guild protocol, a lending term can be offboarded via a governance vote in `LendingTermOffboarding`, setting the `canOffboard[term]` flag to true. After offboarding, the flag is intended to be cleared by calling `cleanup()` once all outstanding loans are closed. However, if governance re-onboards the term while active loans are still closing, `canOffboard[term]` remains set to true. An unprivileged attacker can take advantage of this stale state to immediately invoke `offboard()` on the newly re-onboarded term, bypassing the DAO voting mechanism and prematurely terminating active lending terms.
Collective: `encodedData` argument of `hashStruct` is not calculated perfectly for EIP712 singed messages in `CultureIndex.sol`
The protocol incorrectly implements EIP-712 message signing for structures containing dynamic arrays. Specifically, the `CultureIndex` contract performs improper encoding of the `pieceIds` array, failing to hash its contents as required by the EIP-712 specification. This discrepancy between off-chain signature generation and on-chain verification causes valid user signatures to be rejected, effectively breaking the voting mechanism.
Biconomy: Destruction of the `SmartAccount` implementation
An uninitialized logic implementation contract in Biconomy's SmartAccount allows any external attacker to call `init` and claim ownership of the base implementation contract. Once ownership is gained, the attacker can execute a `delegatecall` to a malicious contract containing a `selfdestruct` instruction. Destroying the logic implementation contract permanently freezes all proxy user wallets relying on this implementation, bricking funds across all deployed smart accounts.