# Signature Checks could be passed when SignatureDecoder.recoverKey() returns 0

Signature validity check in Rigor Project.sol passes when recoverKey() returns 0, letting any user call changeOrder/setComplete after an approved hash exists.

- Payout: Contest reward
- Severity: medium
- Program: Rigor Protocol
- Credited: cryptphi
- Disclosed: 2022-09-12
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-08-rigor-findings/issues/179
- Library page: https://bugbountylibrary.com/r/c4%3A2022-08-rigor%3AM-03
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:access-control vuln:auth-bypass vuln:signature-replay

**Target:** Solidity smart contract signature validation (Project.sol)
**Root cause:** checkSignatureValidity() compares recovered signer against approved hash mapping but never rejects a zero-address recovery result, so ecrecover returning 0 can match an unset/zero entry.
**Steps:**
1. Builder/contractor approves a data hash so an approved entry exists
2. Attacker crafts a signature that makes SignatureDecoder.recoverKey() return address(0)
3. Call changeOrder or setComplete with that signature
4. checkSignatureValidity() passes because recovered key 0 is not rejected
**How found:** Code review of checkSignatureValidity() and recoverKey() usage, noticing the missing zero-address guard on the recovered signer.
**Exploitation:** Any user submits a malformed signature yielding recoverKey()==0 to changeOrder/setComplete once an approved hash exists, bypassing the signer requirement and mutating order state.
**Insight:** When validating ecrecover-based signatures, always require the recovered address to be non-zero; a zero result can silently match unset mappings or default values.