The functions Soulmate::mintSoulmateToken
and Airdrop::claim
contains an inconsistency where users who are in waiting list and have not been matched with a soulmate can still claim tokens because of the ownerToId mapping returning a token ID that is set to nextID
when a user first calls mintSoulmateToken, leading to claiming of Airdrop without having a soulmate while still being in the waitlist.
The vulnerability occurs due to insufficient checks inside Airdrop::claim
function as a result of which it considers users still in waiting list for soulmate are able to claim LoveToken from Airdrop.
A user calling Soulmate::mintSoulmateToken
when there is no user assigned to nextID
, then that user will be assigned the nextID
in the mapping ownerToId
, but notice that the user currently has no soulmate and is waiting for them to call it.
But before the next user calling mintSoulmateToken
, the first user will be eligible to claim Airdrop as Aidrop::claim
function doesn't implement proper check whether the user has a soulmate or not.
Here the ownerToId
for the user will be the nextID
and corresponding to that nextID, no nft is created therefore idToCreationTimestamp
for that token id will be 0
and the user will be able to claim a large number of LoveToken.
Users currently in waiting list for other users are able to claim Aidrop by a bigger amount.
Add the test in the file: test/unit/AirdropTest.t.sol
and also import console2
from forge-std/Test.sol
Run the test:
Manual Review, Unit Test in Foundry
Add a check in the Aidrop::claim
function that if a user is in waiting list then they should not be able to claim Aidrop.
High severity, This issue is separated from the flawed `isDivorced()` check presented in issue #168 as even if that is fixed, if ownership is not checked, isDivorced would still default to false and allow bypass to claim airdrops by posing as tokenId 0 in turn resulting in this [important check for token claim is bypassed.](https://github.com/Cyfrin/2024-02-soulmate/blob/b3f9227942ffd5c443ce6bccaa980fea0304c38f/src/Airdrop.sol#L61-L66). #220 is the most comprehensive issue as it correctly recognizes both issues existing within the same function.
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.