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.