Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Ethereum's ecrecover precompile can accept two ECDSA encodings for the same message and signer. Given a valid secp256k1 signature (r, s), replacing s with the curve order minus s and changing the recovery identifier produces the alternate form. This does not create a signature for a new message and does not reveal the private key. It becomes a contract vulnerability when code mistakes signature bytes for a unique authorization.
A common vulnerable pattern records keccak256(signature) as used. An observer can transform a valid low-s signature into its high-s counterpart. The byte hash changes, but raw ecrecover can recover the same signer, so the authorization may execute twice.
EIP-2 made high-s Ethereum transaction signatures invalid at the protocol layer. It deliberately left the ecrecover precompile unchanged, so application contracts must still canonicalize signatures. Transaction canonicalization therefore does not protect a contract that verifies arbitrary signed messages.
Malleability is distinct from replay. Low-s enforcement rejects the alternate high-s form; it does not make an authorization single-use, bind it to a contract or chain, or impose an expiry. A nonce or unique operation identifier is still required.
Review every raw ecrecover call and every library wrapper around it. Confirm that s is in the lower half of the secp256k1 order, that the recovery identifier is accepted in the expected form, and that a zero recovered address cannot pass authorization. Then trace how the contract marks an action used. The replay key should represent the signed action or consume a signer nonce, not hash the signature encoding.
A focused test should submit a valid signature and its mathematically equivalent high-s form. Verification should reject the alternate form. Separate tests should show that a second canonical signature for an already-consumed nonce also fails.
Firepan can inspect signature recovery and replay-key logic in a submitted repository and commit. It reports scoped evidence; it does not certify all off-chain signing code or continuously monitor deployed contracts.
OpenZeppelin's ECDSA library rejects signatures whose s value is not in the lower half order and restricts v to 27 or 28. Use a version compatible with the repository rather than reimplementing curve constants. For EOAs, verify the correctly constructed digest and consume the action nonce before making external calls. If contract wallets are supported, use an ERC-1271-aware verifier and test its state-dependent validity semantics.
Do not describe the alternate encoding as a forged authorization. Both forms prove the same signer approved the same digest. The security failure is accepting a second byte representation as a second action.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Assess smart contract admin powers, upgrade authority, key custody, delays, caps, and the limits of source-only centralization analysis.
Review smart contract liveness failures caused by gas growth, external-call reverts, griefing, and unrecoverable state.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Review accounting assumptions for fee-on-transfer, rebasing, and other non-standard ERC-20 tokens, with test and mitigation guidance.
Understand transaction-ordering risk, sandwich attacks, the conditions that make them profitable, and practical review and mitigation techniques.