The getReferrerAddress function does not validate the referralCode data before decoding it using abi.decode. This can lead to unexpected behavior or errors if referralCode does not contain a valid address.
The function assumes that referralCode has a valid address format when isCustomReferralCode is false, which might not always be the case, leading to potential runtime errors.
Code snippet:
Here’s a foundry fuzz test to ensure referralCode is valid before decoding it:
Run forge test --match-contract ReferralTest -vvv
Output: [FAIL. Reason: EvmError: Revert; counterexample: calldata=0x2c8ccc5a000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000145bcbf976ac72b347c17b654d9c3a66964f940a8a000000000000000000000000 args=[0x5bcbf976ac72b347c17b654d9c3a66964f940a8a]] testValidReferralCodeDecoding(bytes) (runs: 5, μ: 37759, ~: 30735) Traces: [26382] ReferralTest::testValidReferralCodeDecoding(0x5bcbf976ac72b347c17b654d9c3a66964f940a8a) └─ ← [Revert] EvmError: Revert
Severity: High
Impact on the Protocol: Decoding incompatible or maliciously crafted referralCode can lead to runtime errors or potentially execute unintended logic, directly impacting contract functionality.
Likelihood of Exploitation: High. Without validation, it is highly probable that invalid referralCode data could lead to exploitation.
Manual code review
Foundry fuzz testing
Add validation logic to ensure referralCode is in a valid format before decoding it.
Example Fix:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.